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SECTION  I 


INTRODUCTION 


A.  WHY  ASD  USES i LCOM 

The  environment  of  increasingly  complex  weapon  systems  and  equally 
complex  support  systems  has  created  a  requirement  for  improved  scientific 
tools  to  assist  in  the  evaluation  of  these  systems.  A  technique  was  needed 
that  permitted  a  systematic  approach  to  analysis  of  the  support  requirements 
for  complete  weapon  systems.  Computer  simulation  was  selected  as  the  best 
means  of  analyzing  support  systems  on  an  item-by-item  basis  in  terms  of  their 
effect  on  operating  performance.  Although  the  initial  interest  was  in 
logistics  support  areas,  simulation  further  permitted  an  across-the-board 
analysis  of  other  types  of  support  resources,  i.e.,  men,  test  equipment,  etc. 

Logistics  Composite  Model  (LCOM)  software  employs  simulation  to  analyze 
the  impact  of  all  types  of  support  resource  shortages  on  the  operational 
status  of  a  weapon  system.  The  LCOM  software  together  with  the  data 
representing  a  weapon  systems  environment  form  study  models  that  permit  the 
analysis  of  the  weapon  systems  support  requirements. 

The  Aeronautical  Systems  Division  (ASD)  currently  uses  the  LCOM  for  two 
Department  of  Defense  (DOD)  directed  requirements.  The  first  require.  .;nt  is 
to  develop  manpower  requirements;  the  second,  to  verify  the  supportability 
and  maintainability  of  major  weapon  systems. 

DODI  5000.2  and  AFR  800-15  provide  the  justification  for  the  manpower 
use  of  LCOM  in  systems  acquisition. 

....manpower  and  personnel  factors,  to  include  numbers, 
occupations,  and  skill  levels  of  manpower  required,  shall 
be  included  as  considerations  and  constraints  in  system 
design.  (29) 

....Insure  that  tradeoffs  (trade  studies)  to  reduce  manpower 
requirements  are  conducted  within  the  context  of  the  planned 
operational  and  support  concepts  and  with  full  consideration 
of  life  cycle  costs.  Insure  that  the  potential  manpower 
impact  of  proposed  cha"n 's  to  design,  logistics  support,  or 
employment  are  adeqi  -<  „  assessed.  (17:3) 

In  September  1980,  HQ  AFSC  proposed  that  System  Readiness  information  be 
included  in  the  Secretary  of  the  Air  Force  Program  Reviews  (SPRs).  (See 
Attachment  1).  The  LCOM  will  be  used  to  show  the  ability  of  aircraft  weapon 
systems  to  sustain  wartime  operations  and  provide  input  for  a  “Systems 
Readi ness-Sustai nabi 1 i ty "  chart . 

ENESA  is  the  focal  point  for  ASDs  use  of  LCOM.  The  LCOM  software  is 
maintained  by  the  Air  Force  Maintenance,  Supply,  and  Munitions  Management 
Engineering  Team  (AFMSMMET),  Wright-Patterson  AFB,  OH. 
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B.  GENERAL  FLOW  PROCESS  OF  LCOM  AT  ASD 

Figure  1  shows  the  major  elements  in  the  modeling  of  new  weapon  systems. 

The  maintenance  ta,sks  required  on  the  new  aircraft  are  estimated  using  Air 
Force  experience  ■with  similar  subsystems  in  existing  aircraft  plus  a  factor 
which  may  be  applied  for  differences  in  design.  This  experience  data  is 
obtained  from  Maintenance  Data  Collection  System  (MDC)  data  processed  through 
the  Common  Data  Extraction  Programs  (CDEP).  (4)  Block  1  in  Figure  1 
represents  use  of  the  CDEP  to  obtain  comparable  data  from  a  number  of  current 
aircraft.  Block  2  shows'  the  operations  and  maintenance  scenario  that  must  be 
constructed  for  the  new  aircraft.  Using  command  inputs  are  needed  at  this 
point.  When  processed  through  a  series  of  translation  programs,  these  data 
are  the  input  to  Block  3,  the  LCOM  simulation. 

The  simulation  model  determines  the  manning  for  the  given  scenario. 

Other  directed  analysis,  such  as  trade-off  studies,  would  require  different 
simulations.  In  Block  4,  results  from  simulation  runs  are  used  to  compute 
regression  curves  for  manpower  and  other  directed  analyses. 

The  LCOM  scenario  contains  all  assumptions,  operating  policies  and  flying 
schedules.  Therefore,  the  LCOM  results  are  different  for  each  scenario.  For 
example,  a  typical  wartime  model  would  require  shorter  task  times,  no  shop 
support,  and  deferrable  maintenance  when  compared  to  a  peacetime  model. 
Different  analysis  requirements  may  also  dictate  different  levels  of  model 
complexity  and  methodologies  used. 

C.  HOW  THE  SIMULATION  WORKS 

The  necessary  inputs  to  the  LCOM  include:  Daily  mission  schedules 
(defining  when  aircraft  are  to  fly  and  for  how  long),  main  aircraft  servicing 
networks  (defining  the  tasks,  times,  and  resources  to  prepare  and  launch  an 
aircraft  at  its  scheduled  time  and  service  it  on  return),  corrective 
maintenance  networks  (defining  the  tasks,  times,  and  resources  to  fix  each 
subsystem  when  it  breaks),  failure  rates  (defining  how  frequently  each 
subsystem  is  likely  to  require  corrective  maintenance),  and  the  quantities  of 
each  resource  (aircraft  by  type,  men  by  AFSC  and  shift,  LRU  spares  and  support 
equipment  (AGE)). 

Figure  2  shows  a  simplified  diagram  of  how  the  simulation  uses  these 
inputs  to  simulate  a  sequence  of  maintenance  activities  that  would  take  place 
in  an  operational  unit  flying  a  specified  schedule.  Initially,  resource  levels 
are  entered  into  the  simulation  to  provide  a  pool  from  which  resources  are 
subsequently  drawn. 

When  the  schedule  calls  for  an  aircraft  to  start  preparation  for  a 
mission,  the  simulation  checks  the  number  of  aircraft  in  available  status  " 
(those  not  flying  or  in  maintenance)  and  assigns  (or  reconfigures)  those  needed 
for  the  mission.  Each  of  the  assigned  aircraft  then  begins  processing  through 
the  appropriate  main  aircraft  servicing  network,  using  the  resources  needed  for 
the  time  specified  in  the  task  data.  The  simulation  keeps  records  on  each 
resource.  For  example,  when  all  load  teams  are  already  working  on  tasks  of 
equal  or  higher  priority,  the  loading  task  on  another  aircraft  will  be  delayed 
(or  placed  on  backorder  status)  until  a  load  team  becomes  available. 
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Figure  1.  Model  Development  and  Operation. 


Figure  2.  How  the  Simulation  Works. 


At  scheduled  takeoff  time,  if  enough  aircraft  are  ready  to  go,  the  planes 
are  launched  and  "fly"  for  the  specified  mission  duration.  At  the  end  of  this 
time,  they  return  to  base  and  process  through  the  post  sortie  servicing  and 
maintenance  tasks. 

The  simulation  maintains  a  failure  clock  for  each  subsystem.  (A  failure 
clock  is  a  counter  telling  how  often  a  failure  occurs.)  A  random  draw  is  made 
from  a  subsystem  failure  distribution  to  determine  the  number  of  sorties  until 
the  next  corrective  maintenance  action  on  that  subsystem  will  be  required. 
Whenever  an  aircraft  processes  pre-  or  post-sortie,  each  subsystem  is  checked 
for  failure.  If  any  failures  occur,  the  simulation  lists  it  as  a  required 
corrective  maintenance  action  on  that  aircraft.  The  tasks  in  the  corrective 
maintenance  network  for  that  subsystem  must  be  completed  before  the  aircraft 
can  be  returned  to  available  status. 

The  lower  the  initial  resource  levels  (the  more  constrained),  the  more 
tasks  are  delayed;  aircraft  take  longer  to  return  to  available  status,  and 
fewer  missions  are  completed.  The  extent  of  the  mission  loss  depends  on  the 
timing  of  the  mission  schedule  and  resultant  backordering  of  resource  demands. 

D.  RELATIONSHIP  OF  THE  INPUT  FORMATS 

The  hierarchic  relationships  among  input  data  are  shown  in  Figure  3.  An 
operations  schedule  is  contained  on  LOOM  Forms  20  (AF  Form  2720).  Forms  21, 

22  and  23  (AF  Form  2721,  2722,  and  2723,  respectively)  define  the  decision 
rules  to  use  in  picking  the  appropriate  aircraft.  LOOM  Form  17  (AF  Form  2717) 
identifies  the  appropriate  main  aircraft  servicing  network  for  each  mission 
type.  These  networks  are  initially  coded  and  entered  into  the  data  base  on 
Extended  11  Forms  (AF  Form  2719).  These  Extended  11  Forms  are  converted  later 
to  LOOM  Forms  10,  11,  12,  13  and  14.  (AF  Form  2710,  2711,  2712,  2713,  and 
2714,  respectively)  (NOTE:  Oo  not  confuse  the  Extended  11  Forms  with  LOOM 
Form  11;  they  are  not  the  same.)  Networks  define  the  sequencing  of  tasks  to 
be  accomplished  and  the  time  and  resources  required  for  each  task.  The  main 
networks  also  contain  appropriate  clock  decrements  and  call  tasks.  Decrement 
tasks  specify  when  and  on  what  basis  clocks  are  to  be  decreased,  and  the  call 
tasks  specify  when  these  clocks  are  to  be  checked  and  any  required  maintenance 
accomplished.  The  corrective  maintenance  networks  and  the  failure  distributions 
for  each  subsystem  are  entered  into  the  data  base  on  Extended  11  Forms  as  well. 
(The  Extended  11  Form  will  be  discussed  in  greater  detail  in  a  later  chapter.) 
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Figure  3.  Relationship  of  Inputs. 


SECTIG.v  II 


DEFINING  AN  OPERATIONS  SCHEDULE 
A.  COORDINATING  THE  ASSUMPTIONS 

Often,  the  most  difficult  step  in  building  an  operations  scenario  is 
getting  agreement  on  the  specific  mission  requirements.  These  requirements 
must  be  coordinated  and  agreed  to  among  the  decision  makers  and  organizations 
who  are  going  to  use  the  end  results.  Few  combat  aircraft  have  only  a  single 
mission  and  single  possible  modes  of  operation  in  all  situations.  Operations 
scenarios  can  range  from  a  low  sustaining  rate  of  peacetime  training  flying  by 
a  full  wing  at  an  established  CONUS  (Continental  United  States)  base,  to  a 
round-the-clock  combat  surge  by  a  single  squadron  deployed  at  a  forward  base. 
Scenarios  must  be  defined  that  are  appropriate  to  the  decisions  and  plans  that 
will  be  made  with  the  model  results.  For  example,  the  CONUS  wing  training 
scenario  cannot  be  used  to  determine  manning  for  a  deployed  squadron  in  combat. 

The  requirements  office  in  the  operating  command  is  a  primary  source  of 
information  on  operations  plans  for  new  aircraft. 

The  following  information  should  be  included  in  a  Scenario  for  use  in 
LCOM.  Items  listed  are  to  be  used  as  a  checklist  and  should  be  added  to  or 
deleted  as  appropriate  for  the  particular  aircraft  and  situation  being  modeled, 
and  included  in  the  final  report. 

a.  General  Requirements: 

(1)  Organization  level  and  unit  equippage  (UE:  also  referred  to 
as  PAA,  Program  Authorized  Aircraft)  by  aircraft  type. 

(2)  Manpower  availability  (manhours  per  month). 

(3)  Percentage  of  available  manhours  which  must  be  allowed  for 
indirect  work. 

(4)  Standard  manning  for  Chief  of  Maintenance  overhead  and  for 
any  workcenters  which  will  not  be  simulated. 

(5)  Acceptable,  Not  Mission  Capable  Supply  (MNCS)  rate. 

b.  Facilities  and  Deployment: 

(1)  Number  of  locations  and  UE  (PAA)  sizes  at  each  location. 

(2)  Resupply  time. 

(3)  Allocation  of  equipment,  such  as  support  equipment  (AGE)  at 
each  location. 

(4)  Extent  of  maintenance  capability  required  at  each  location. 

(5)  Shelters  and  facilities  at  each  location. 
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c.  Mission  Requirements:  Identify  mission  types.  Specify  the 
following  mission  requirements  for  each  mission  type;  or  each  leg  of  each 
mission  involving  enroute  sorties. 

(1)  Percent  of  total  sorties. 

(2)  hirer aft  type. 

(3)  Initial  configuration  (e.g..  numbers  and  types  of  external 
tanks,  ECM  pods,  cameras,  guns,  missiles,  bombs,  cargo  handling  and  passenger 
comfort  equipment,  etc.). 

(4)  Probability  of,  and  quantity  of,  load  expended  (e.g.,  tank 
jettision,  air-to-air  missile  firing,  etc.)  by  mission  type. 

(5)  Ending  configuration  and  disposition. 

(6)  Substitution  rules  for  using  alternate  configurations. 

(7)  Mission  Priority. 

(8)  Flight  sizes  (maximum,  minimum)  and  policy  of  sympathetic 
ground  abort  and  spares. 

(9)  Mean  sortie  length  and  variation. 

(10)  Recovery  or  enroute  point  (if  not  returning  to  same  base). 

(11)  Probability  and  conditions  of  air  refuel. 

(12)  Proportion  flown  at  night. 

(13)  Weather  limitations  by  mission  type  (e.g.,  for  bomb  delivery, 
air  refuel,  air  engagement,  etc.). 

(14)  Length  of  delays  that  can  be  tolerated  before  mission 
cancellation  (e.g.,  for  weather,  maintenance,  etc.). 

*  (15)  Extent  of  operation  of  mission  peculiar  equipment  (e.g., 

photographic  equipment,  if  mission  calls  for  reconnaissance.) 

(16)  What  missions  will  have  sympathetic  ground  and/or  aborts? 

d.  Operations  and  Scheduling  Policy: 

(1)  Base  and  target  weather  miniraums  for  launch  and  recovery. 

(2)  Conditions  for  air  abort  (including  sympathetic). 

(3)  Policy  for  ground  and/or  airborne  spare  aircraft. 

(4)  Desired  percent  of  available  aircraft  which  will  be  turned  to 
fly  again  the  same  dqy,  if  possible. 
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frame. 


(5)  Requirements  for  massed  launch  within  a  restricted  time 


(6)  Requirements  for  complimentary  missions  and  mission  legs 
within  a  restricted  time  frame. 

(7)  Definition  of  day  missions  (e.g.,  between  0600  and  1800 

hours). 

e.  Ground  Alert: 

(1)  Number  of  aircraft  on  alert  per  UE  (PAA). 

(2)  Which  mission  flown  from  alert,  as  identified  in  paragraph  c 

above. 

(3)  Frequency  of  alert  missions. 

(4)  Replacement  policy  (e.g.,  replacement  when  launched,  or  same 
aircraft  return  to  alert.) 

(5)  Duration  of  alert  cycle. 

(6)  Disposition  at  end  of  alert  cycle. 

(7)  Aircraft  acceptance  and/or  alert  quick  turn  policy  and 

procedures. 

(8)  Policy  for  dedicating  personnel  and  equipment  to  alert. 

f.  Functional  Check  Flights  (FCF): 

(1)  Conditions  requiring  FCF. 

(2)  Limitations  on  FCF  (e.g.,  daylight  only). 

(3)  FCF  duration  and  probable  range  of  variation. 

g.  Maintenance  Concepts  and  Organizations: 

(1)  Organizational  structure  (e.g.,  per  AFR  66-1). 

(2)  AFSC  structure  (e.g.,  integrated  avionics  versus  functional 
avionics  specialists). 

(3)  Quick  turn  conditions  and  procedures,  including  extent  of 
deferred  maintenance. 

(4)  Remote  versus  home  station  maintenance,  including  criteria 
for  deferred  maintenance. 

(5)  Policy  for  launch  support. 

(6)  Conditions  requiring  download  of  munitions. 


h.  Combat  Damage: 

(1)  Identify  the  probability  of  attrition  and  battle  damage. 

(2)  Probability  of  an  aircraft  returning  from  battle  damage 
requiring  a  Rapid  Aircraft  Maintenance  (RAM)  team  and/or  reserve  augmentation. 

(3)  Policy  for  allocating  combat  damage  repair  to  base,  RAM  team 

and  depot. 

i.  Crew  Ratio  Study  Assumptions: 

(1)  Identify  by  mission  type: 

(a)  The  time  before  scheduled  takeoff  that  briefing  should 

begin. 

(b)  The  time  after  landing  when  debriefing  will  be 

completed. 

(c)  Any  reduction  in  briefing/debriefing  time  when 
missions  are  flown  in  succession. 

(2)  Describe  aircrew  scheduling  rules: 

(a)  Formed  crews. 

(b)  Multiple  seat  qualifications. 

(c)  Flight  lead  or  special  qualifications. 

(d)  Squadron  Integrity. 

(e)  Additional  duty  requirements  (if  applicable,  Identify 
additional  duties  and  hours  required  per  shift. 

(f)  Maximum  flight  duty  period, 

(g)  Minimum  crew  rest  periods. 

(h)  Days  off  policy. 

(1)  Probability  of  aircrew  recovery  after  being  shot  down. 

(j)  Maximum  number  of  missions  per  flight  duty  period. 

(k)  Overhead  posture. 

(3)  If  applicable.  Identify  specific  excursion  requirements. 

(AFR  25-8  establishes  procedures  for  obtaining  an  approved  ICON  scenario.) 


SECTION  III 


MISSION/SORTIE  ANALYSIS 


A.  GENERAL 

The  LCOM  provides  great  flexibility  in  establishing  missions,  sorties, 
and  activities  that  an  aircraft  can  perform.  It  also  provides  limited 
capability  for  defining  external  and  Internal  configuration  for  each  aircraft. 
This  allows  the  modeler  to  specify  different  classes  and  different  internal 
configurations  of  aircraft  for  different  missions. 

The  modeler  follows  a  hierarchy  in  classifying  an  aircraft.  This  is 
depicted  by  Figure  4.  The  “aircraft  type"  Is  stipulated  on  the  Form  20  and 
reflects  the  weapon  system  modeled.  This  is  the  first  level  of  the  hierarchy. 

The  second  level  concerns  the  aircraft  class.  It  Is  depicted  on  the 
Form  17  and  normally  corresponds  to  the  types  of  missions  required,  i.e., 
close-air-support  (CAS),  interdiction  (INTD),  combat-air-patrol  (CAP',  etc. 

This  level  and  the  next  are  where  external  configurations  are  primarily  used. 

The  next  level  is  the  status  of  the  aircraft.  An  aircraft  can  be 
maintained  by  external  configuration  In  one  of  three  states:  (1)  available, 

(2)  cocked,  and  (3)  in  use.  An  aircraft  is  considered  available  if  it  Is 
ready  for  assignment,  but  requires  the  processing  of  pre-sortie  tasks  before  a 
sortie  can  be  accomplished.  A  cocked  aircraft  is  one  that  could  fly 
immediately  on  some  missions,  that  is,  it's  fully  configured  and  requires  no 
processing  of  pre-sortie  tasks.  It  begins  the  mission  at  the  sortie  task. 
However,  a  cocked  aircraft  assigned  to  a  mission  that  requires  the  aircraft  to 
be  reconfigured  will  become  an  available  aircraft  and  will  process  pre-sortie 
tasks.  An  in-use  aircraft  is  processing  some  piece  of  network  or  is  on  the 
sortie  task.  Available  and  cocked  aircraft  are  both  capable  of  being  assigned 
to  mission  requirements.  In-use  aircraft  are  not  available  for  assignment. 

The  last  level  of  Figure  4  represents  the  Internal  configuration  of 
aircraft.  Each  aircraft  Is  capable  of  having  a  unique  set  of  Internal 
equipment.  These  unique  sets  are  described  by  Internal  equipment  groups. 

The  forms  that  the  modeler  has  at  his  disposal  for  raission/sortie 
definition  are  the  AF  Form  2717  (Form  17),  Mission  Entry  Points;  the  AF  Form 
2720  (Form  20),  Sortie  Generators;  the  AF  Form  2721  (Form  21),  Aircraft 
Assignment  Search  Patterns;  the  AF  Form  2722  (Form  22),  Internal  Equipment 
Authorizations/Changes;  and  the  AF  Form  2723  (Form  23),  Internal  Equipment 
Group  Definitions.  Forms  22  and  23  are  only  required  if  Internal  configuration 
is  desired.  Forms  17,  21,  and  20  are  necessary  for  each  simulation. 

B.  CONFIGURATION  MANAGEMENT 

Configuration  management  allows  the  users  of  LCOM  to  maintain  significant 
external  control  of  aircraft  usage.  This  control  considers  the  aircraft's 
configuration  which  can  be  in  terms  of  either  external  or  Internal 
configuration,  or  both. 

External  configuration  Is  normally  descriptive  of  the  ordinance  loading  of 
an  aircraft,  or  anything  externally  mounted  that  could  change  the  aircraft's 
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Figure  4.  Aircraft  Classification  Hierarchy. 


use  characteristics;  for  example,  bombs,  missiles,  racks,  etc.  Internal 
configuration  refers  to  a  specific  piece,  or  set  of,  internal  equipment,  whose 
condition  (availability  on  the  aircraft)  can  also  change  the  aircraft's  use 
characteristics;  for  example,  a  gun,  or  a  camera.  It  is  used  as  a  method  to 
track  and  model  deferred  maintenance. 

The  modeler  can  control  aircraft  usage  by  configuration,  changes  of 
configuration  through  reconfiguration,  and  selection  based  upon  estimated  times 
to  prepare  the  aircraft  for  missions. 

The  first  step  in  configuration  management  is  an  in-depth  analysis  of  all 
possible  external  and  internal  configurations.  Once  defined,  an  attempt  to 
consolidate  them  into  as  few  different  configurations  as  possible  must  be  made. 
The  ground  rules  for  this  consolidation  process  should  include,  but  not  be 
limited  to,  consideration  of  the  following  five  questions: 

(1)  What  types  of  answers  or  results  am  I  looking  for  and  what  impact 
will  the  different  configurations  have  on  these  results?  Areas  of  prime 
consideration  include  tasks  with  significantly  different  times  or  crew  sizes, 
operational  substitutability,  etc. 

(2)  How  many  of  the  possible  configurations  are  actually  used  and  to 
what  extent?  It  may  be  that  25  different  configurations  are  possible,  but  only 
six  (6)  or  seven  (7)  constitute  95%  of  all  the  missions  flown. 

(3)  During  the  process  of  configuration  changes  (reconfigurations),  are 
there  special  requirements  for  checkout  of  the  configurations,  i.e.,  special 
tasks  or  resources  required? 

(4)  In  terms  of  Internal  configurations,  are  there  any  special  networks 
to  be  developed  and  what  impact  might  they  have  on  aircraft  availability? 

(5)  What  impact  will  reconfigurations  have  on  aircraft  pre-sortie  time? 

1.  EXTERNAL  CONFIGURATION 

As  previously  stated,  aircraft  are  maintained  by  external  configuration  in 
one  of  three  states:  (1)  available,  (2)  cocked,  and  (3)  in  use.  When  an 
aircraft  completes  its  flight  and  all  its  maintenance  (reaches  the  end  of  (main) 
network),  an  attempt  is  made  to  immediately  reassign  it  to  any  mission.  If  it 
is  not  needed,  it  is  placed  in  the  post-sortie  external  configuration.  Cocked 
aircraft  are  aircraft  that  completed  pre-sortie  processing  for  a  mission  (as 
prime  or  spare),  but  did  not  fly.  For  example,  if  an  aircraft  is  in  pre-sortie 
unscheduled  maintenance  and  the  mission  cancels,  the  aircraft  will  complete 
processing  to  the  sortie  task.  They  carry  the  pre-sortie  external 
configuration  class  (defined  on  Form  17)  of  the  mission  they  missed. 

When  a  mission  or  activity  from  the  Form  20  file  Is  requested,  the  Form  17 
is  referred  to.  The  Form  17  specifies  which  aircraft  assignment  search  pattern 
the  simulation  should  follow.  The  Form  21  defines  these  search  patterns,  the 
sequential  order  of  aircraft  configurations  acceptable  for  the  mission,  and  how 
these  aircraft  configurations  are  to  be  reconfigured  to  meet  the  mission 
requirement.  External  configuration  can  be  used  to  represent  weapons  load  and 
other  mission-related  configurations.  Each  aircraft,  by  tail  number,  Is 
identified  by  a  particular  configuration.  All  aircraft  are,  at  the  start  of 
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simulation,  configured  as  the  first  configuration  specified  on  the  Form  17  or 
as  the  configuration  specified  on  a  “STORAC"  change  card.  Dummy  activities 
can  be  used  at  simulation  time  zero  to  establish  the  proper  proportion  of 
aircraft  per  external  configuration. 

Each  search  pattern  listed  on  the  Form  21  has  an  ordered  list  of 
configurations  to  examine.  Each  aircraft  is  examined  and  compared  to  this 
list  of  configurations.  If  a  match  Is  found,  the  aircraft  is  entered  into  the 
reconfiguration  entry  mode  for  that  configuration.  This  entry  mode  defines 
the  network  of  tasks  needed  to  prepare  the  aircraft  for  the  mission. 

The  cut-off  time  specified  for  each  searched  configuration  allows  more 
efficient  selection  of  aircraft.  If  the  remaining  time  to  mission  cancellation 
is  less  than  the  specified  cut-off  time  for  a  listed  configuration,  that 
configuration  is  skipped  and  the  search  is  continued.  If  the  minimum  aircraft 
listed  on  Form  20  have  already  been  assigned  and  are  ready  to  fly,  the  cut-off 
time  test  uses  the  scheduled  takeoff  time  instead  of  cancel  time.  If  the 
cut-off  times  are  properly  based  on  task  times  for  reconfiguration  and 
pre-sortie  processing,  this  feature  will  prevent  aircraft  from  being  prepared 
for  missions  they  cannot  make.  Space  is  provided  for  two  (2)  configuration 
choices  on  each  line  of  the  Form  21.  Continuation  cards  ("C"  in  Column  11)  can 
be  used  for  additional  configuration  choices  for  the  same  mission  name.  The 
order  of  search  for  a  given  mission  name  is  first  line  left  entry,  first  line 
right  entry,  second  (continuation)  line  left  entry,  second  line  right  entry, 
third  (continuation)  line  left  entry,  etc. 

If  a  Form  21  calls  for  a  cocked  aircraft  and  blank  reconfiguration  modes, 
the  aircraft  will  go  directly  to  the  sortie  task,  bypassing  through  all 
pre-sortie  processing  in  zero  time.  This  can  be  unrealistic  in  some 
situations  where  pre-sortie  launch  networks  should  be  processed  by  cocked 
aircraft.  To  correct  this  it  is  suggested  that  external  configuration  networks 
be  used  to  identify  loading  tasks  and  preflight  tasks.  Pre-sortie  networks 
should  only  Include  launch  tasks  (walkaround,  engine  start,  etc.).  Whenever 
aircraft  process  any  reconfiguration  network  (this  could  be  simply  a  dummy 
task),  they  will  process  the  pre-sortie  network.  This  is  because  cocked 
aircraft  are  converted  to  available  aircraft  whenever  a  reconfiguration  network 
is  entered.  The  user  must  take  care  to  assure  that  all  possible  configurations 
that  could  occur  in  the  course  of  the  simulation  have  some  disposition  on 
Form  21.  This  can  be  accomplished  by  running  the  flying  schedule  preprocessor 
program. 

2.  INTERNAL  CONFIGURATION 

Each  aircraft  can  be  identified  as  having  a  unique  group  of  Internal 
equipment  Items  (such  as  gun,  camera,  radio,  TACAN,  etc.)  functioning.  This 
is  known  as  internal  configuration  and  is  defined  and  specified  on  Forms  21, 

22,  and  23.  (AF  Forms  2721,  2722,  and  2723,  respectively). 

Form  21  lists  the  equipment  group  name  of  equipment  Items  needed  for  the 
particular  mission.  This  equipment  group,  which  is  defined  on  Form  23, 
specifies  a  unique  combination  of  Internal  equipment.  It  lists  the  equipment 
name  as  well  as  the  minimum  quantity  required  for  a  mission.  For  example,  if 
an  aircraft  has  two  (2)  cameras  operational  and  the  equipment  group  on  Form  23 
specifies  two  (2),  one  (1),  or  zero  (0)  cameras,  the  aircraft  will  satisfy  that 
equipment  group.  The  user  should  be  extremely  careful  to  insure  all  possible 
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combinations  of  equipment  are  considered  on  Form  23.  For  this  reason,  the 
number  of  internal  equipment  items  to  be  considered  for  internal  configuration 
should  be  kept  to  a  minimum. 

Once  an  aircraft  is  found  that  satisfies  the  internal  equipment  group 
listed  on  the  Form  21,  the  simulation  will  have  the  aircraft  enter  the  internal 
recoginition  entry  node,  if  one  is  listed,  on  the  Form  21.  This  network  will 
take  the  necessary  actions  to  change  the  aircraft  internal  equipment  to  meet 
mission  needs. 

Form  22  gives  the  network  nodes  which  change  equipment  authorizations. 

As  soon  as  an  aircraft  enters  this  node,  the  equipment  is  decremented  or 
incremented  by  one  (1)  unit.  These  trigger  nodes  must  have  a  "T"  selection 
mode  coded  on  the  Form  11.  No  other  tasks  should  be  placed  in  parallel  with 
these  "T"  selection  mode  tasks.  The  "T"  selection  mode  has  the  same 
characteristics  as  the  “D"  selection  mode.  "T"  nodes  that  subtract  are 
usually  placed  following  the  failure  clocks  in  lieu  of  the  repair  networks. 

"T"  nodes  which  add  are  placed  in  front  of  the  repair  networks  with  the  entry 
node  specified  on  the  Form  21.  Form  22  also  sets  the  authorized  quantity. 

Each  aircraft  is  initialized  to  this  authorized  quantity  at  the  start  of 
simulation. 

3.  RECONFIGURATION  SUMMARY 

Reconfiguration  is  that  action  which  takes  an  aircraft  of  one 
configuration  and  converts  it  to  another  configuration.  Special  networks  are 
defined  by  the  user  for  this  purpose.  In  the  case  of  external  configurations, 
those  networks  might  contain  tasks  which  download  one  type  of  ordinance  and 
upload  another  or  the  upload  of  ordinance  on  a  clean  aircraft.  In  the  case  of 
internal  configurations,  those  networks  might  contain  tasks  that  repair  a  type 
of  internal  equipment.  The  user  must  be  careful  to  insure  that  the  desired 
internal  configuration  is  actually  obtained,  remembering  that  the  equipment 
groups  specify  the  minimum  equipment.  All  other  combinations  with  higher 
equipment  levels  will  satisfy  lower  equipment  level  requirements. 

Generally,  the  first  configuration  in  the  search  pattern  specified  by  a 
mission  is  the  one  requiring  the  least  effort  to  reconfigure.  Normally,  the 
most  acceptable  search  procedure  would  be  to  search  for  a  cocked,  then  an 
available,  aircraft  of  the  required  configuration.  However,  this  is  entirely 
under  user  control  through  the  definition  of  search  patterns  on  the  Form  21. 

C.  CONFIGURATION  MANAGEMENT  EXAMPLE 

To  further  illustrate  the  previous  sections,  the  following  configuration 
management  example  will  be  used.  Figure  5  through  8  are  the  required  networks 
and  Figures  9  through  13  are  the  applicable  Form  20,  17,  21,  23,  and  22. 

The  weapon  system  modeled  Is  called  the  "FX-16'1.  It  is  an  experimental 
fighter  that  will  have  two  mission  types,  MISSIS,  for  missiles,  and  RECON,  for 
reconnaissance.  The  internal  equipment  will  consist  of  a  camera  and  gun.  A 
MISSLS  mission  requires  an  airplane  configured  with  one  camera  and  one  gun.  A 
RECON  mission  requires  an  airplane  configured  with  at  least  one  camera.  Figure 
12  shows  the  possible  combinations  of  Internal  equipment  that  will  occur. 
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At  the  beginning  of  the  simulation,  all  aircraft  are  configured 
externally  as  MISSLS  and  internally  as  GR0UP1  (1  camera,  1  gun).  The 
activity  PRECON,  as  shown  in  Figure  9,  will  occur  at  time  zero  to  externally 
configure  half  of  the  48  aircraft  to  RECON  (internal  configuration  is 
unchanged).  Half  of  the  aircraft  will  be  scheduled  to  fly  MISSLS  missions  at 
0100  each  day  for  the  duration  of  the  simulation  (in  this  example  a  30-aay 
period  is  assumed).  The  remainder  will  be  scheduled  to  fly  RECON  missions  at 
0200.  Since  both  type  missions  are  similar,  we  will  only  discuss  the 
networking  for  a  MISSLS  mission. 

The  simulation  begins  with  a  requirement  for  an  aircraft  to  fly  a  MISSLS 
sortie  at  0100.  The  mission  request,  which  comes  from  the  Forms  20,  actually 
asks  for  an  aircraft  at  scheduled  takeoff  time  (0100)  minus  lead  time  (.20). 
This  is  known  as  the  FRAG  TIME  and  represents  the  actual  simulation  time  the 
mission  request  is  known  to  the  simulation.  In  this  case,  FRAG  TIME  is  at 
0048. 


The  simulation  begins  looking  for  an  aircraft  to  fill  the  mission  request 
by  checking  the  search  pattern  specified  on  the  Form  17  (Figure  10),  in  this 
case,  "SP1".  SP1  is  defined  on  the  Form  21.  The  first  configuration 
specified  is  an  available  MISSLS  with  GR0UP1  internal  configuration. 

If  an  aircraft  with  this  external  and  internal  configuration  is  found,  it 
will  enter  the  network  through  the  entry  node  specified  on  the  Form  17 
(Figure  10);  in  this  example  MN0001 .  The  aircraft  enters  the  network  shown  in 
Figure  5,  pre-sortie  tasks  are  performed,  the  aircraft  flies  the  mission,  and 
after  completing  this  sortie  task,  checks  for  any  failures  in  the  unscheduled 
maintenance  networks.  Unscheduled  maintenance  failures  are  fixed  and  the 
aircraft  completes  post-sortie  tasks  and  is  released  for  another  mission. 

When  the  aircraft  is  released  for  other  missions,  it  is  in  one  of  two 
possible  configurations.  The  first  possible  configuration  is  externally 
configured  as  CLEAN1  and  internally  configured  as  GR0UP1 .  This  only  occurs  if 
no  unscheduled  maintenance  has  been  done.  If  unscheduled  maintenance  has 
occurred  then  the  aircraft  is  configured  as  CLEAN1  and  GROUPS . 

The  change  of  internal  configuration  from  GR0UP1  to  GR0UP3  is  caused  by 
the  call  to  unload  camera  and  gun.  This  happens  after  unscheduled  maintenance. 
Figure  5  shows  these  networks.  The  tasks  SUBGUN  and  SUBCAM  are  defined  with 
the  trigger  selection  (T)  mode.  This  means  the  prior  node  of  these  tasks  are 
defined  (on  Form  22,  Figure  13)  to  subtract  a  value  of  one  (1)  from  the 
aircraft  configuration  list,  thus  making  it  a  GR0UP3. 

The  next  aircraft  the  simulation  searches  for,  if  an  "available"  MISSLS, 
GR0UP1  Is  not  present,  is  a  "cocked"  MISSLS,  GROUP!.  This  aircraft  goes 
through  a  "DUMMY"  node  (See  Figure  8)  with  a  blank  task  name.  This  changes 
the  aircraft  from  a  "cocked"  to  an  "available"  before  beginning  main  network 
processing.  This  causes  the  aircraft  to  process  the  pre-sortie  tasks.  If  it 
had  remained  a  "cocked"  aircraft,  it  would  have  started  processing  at  the 
sortie  task. 

If  another  MISSLS  sortie  is  requested  an  no  "available"  or  "cocked"  MISSLS 
are  in  the  ready  pool,  the  next  aircraft  requested  will  be  an  available  CLEAN1, 
GROUP 1 .  The  mission  requires  MISSLS  external  configuration,  therefore  the 
CLEAN1  must  be  reconfigured  to  meet  this  mission  requirement.  This 
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reconfiguration  is  done  by  entering  the  Form  21  (Figure  11)  reconfiguration 
entry  node,  in  this  case  node  REC003. 

When  the  aircraft  enters  REC003  (See  Figure  8),  a  task  is  accomplished 
to  load  missiles.  After  completing  this  task,  the  aircraft  is  externally 
configured  as  a  MISSLS  and  processing  begins  at  node  MN0001  of  the  main 
network  (See  Figure  5). 

If  an  available  CLEAN1 ,  GROUP!  cannot  be  found,  the  simulation  searches 
for  an  available  CLEAN1 ,  GR0UP3.  This  aircraft  must  be  reconfigured 
externally  and  internally.  The  internal  configuration  occurs  first.  The 
aircraft  enters  the  internal  reconfiguration  node  listed  on  the  Form  21 
(Figure  11),  REC001  (See  Figure  7).  The  tasks  ADDGUN  and  ADDCAM  are  defined 
as  trigger  (T)  nodes  on  the  Form  22  (Figure  13).  After  the  aircraft  completes 
these  tasks,  it  will  be  internally  reconfigured  as  GR0UP1 .  The  aircraft  then 
completes  the  same  external  reconfiguration  as  explained  for  CLEAN2,  GR0UP1 . 

At  this  point,  the  aircraft  has  been  changed  into  a  MISSLS/GR0UP1 
configuration. 

For  example,  aircraft  returning  from  MISSLS  or  RECON  sorties  become 
externally  configured  as  CLEAN1  or  CLEAN2.  These  are  the  post-sortie 
configurations  listed  on  the  Form  17  (Figure  10).  If  for  some  reason  the 
sortie  cancelled,  the  aircraft  would  revert  to  the  pre-sortie  configuration 
listed  on  Form  17  as  "cocked"  aircraft.  In  other  words,  the  pre-sortie 
configuration  defines  the  cocked  configuration  the  aircraft  will  go  into  when 
missions  cancel. 


17 


CO 


CO 

v:  co 

UHU 

tiF-osa: 

<uoo 

XZU.V) 


« 

J-  O  — 

0)  I—  <0 

cn  c  J- 

013  (U 


a 

■« 

o 


« 

£ 

r—  O  O'— 

•S-ESS 

O  3  O  3> 


"O  O  O 
ai  o  c. 
i-  C  3 
3  <0  r— 

•3  C  f 

o  o  « 
o  c  <J 

l/l  t-  T3  O 
tz  <0  C  r— 
3  E  «  o 


18 


Figure  5.  Configuration  Management  Example  -  Main  Network  for  MISSLS 
Sortie  and  Network  to  remove  Internal  Equipment. 
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Ftqure  6.  Configuration  Management  Example  -  Main  Network  for  RECON  Sortie. 


Figure  7.  Configuration  Management  Example  -  Internal  Reconfiguration  Network 
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Figure  10.  Configuration  Management  Example  -  AF  Form  2717  (  Form  17) 


Figure  11.  Configuration  Management  Example  -  AF  Form  2721  (Form  21). 
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Figure  13.  Configuration  Management  Example  -  AF  Form  2722  (Form  22). 


SECTION  IV 


HANDLING  ALERTS 

Alert  missions  are  sorties  randomly  scheduled  throughout  the  flying 
period.  These  missions  are  fulfilled  by  aircraft  which  have  been  specifically 
set  aside  to  meet  the  unforeseen  alert  mission.  In  modeling  a  TAC-based  LCOM, 
the  aircraft  are  kept  in  an  ALERT  POOL  or  CONFIGURATION,  and  only  these 
aircraft  are  searched  to  fulfill  the  mission.  The  alert  mission  has  short 
lead  times  (very  little  notification  as  in  real  life)  and  cancel  times.  They 
are  usually  scheduled  in  flights  of  two  (2).  In  other  words,  the  WIN  and  MAX 
field  is  two  (2).  No  spares  are  scheduled.  The  priority  is  one  (1).  Each 
time  an  alert  mission  occurs,  the  aircraft  which  were  in  the  ALERT  POOL  must 
be  replaced  from  the  fleet  of  aircraft.  This  replacement  is  done  using  alert 
replenishment  activities.  These  activities  are  scheduled  shortly  after  the 
alert  mission,  and  consist  of  all  the  tasks  necessary  to  prepare  the  airplanes 
for  the  ALERT  POOL.  The  same  number  of  alert  replenishments  are  scheduled  as 
alert  missions.  There  should  never  be  more  or  less,  the  MXPOOL  card  is  the 
controlling  factor.  The  replenish  activity  should  have  a  long  cancel  time  to 
insure  that  any  delays  occurring  during  the  alert  mission  are  covered.  When 
ALERTS  are  used  in  the  model,  the  MXPOOL  and  TACMOD  change  cards  must  be  used. 
These  change  cards  prevent  more  than  a  specific  number  of  aircraft  from  being 
available  in  the  ALERT  POOL.  At  the  start  of  simulation,  the  proper  number  of 
alert  replenishment  activities  must  be  scheduled  at  time  zero  (0)  to  initially 
configure  the  ALERT  POOL.  All  replenishment  activities  place  the  aircraft  in 
a  "cocked"  post  activity  configuration.  This  is  specified  by  using  a  three 
(3)  in  column  74  of  the  FORM  20. 

There  is  a  difference  in  how  TAC  and  SAC  schedule  their  alerts.  During 
the  course  of  the  simulation  period,  those  aircraft  on  alert  must  be  released 
from  alert  after  so  many  days.  After  they  are  released,  they  are  used  to 
complete  a  sortie  so  that  the  resources  used  to  prepare  the  aircraft  are  not 
wasted.  Currently,  this  must  be  accomplished  by  manually  scheduling  these 
"first  sorties  after  alert"  missions.  Efforts  are  being  made  to  update  the 
CREATE20  software  to  handle  both  TAC  and  SAC  alert  requirements. 

Figure  10  in  the  previous  section  shows  an  alert  mission  and  its 
applicable  replenish  activity,  ALERTR.  For  simplicity,  an  alert  mission  has 
been  defined  as  requiring  both  c?mera  and  gun  to  be  loaded,  internal  equipment 
GROUP 1 .  This  alert  is  also  similar  to  the  MISSLS  mission  and  will  perform  the 
same  flightline  functions.  The  search  pattern  for  ALERT  are  shown  in  Figure  11. 
Note  that  the  alert  mission  requires  uniquely  defined  alert  aircraft. 


SECTION  V 


NETWORKING  METHODOLOGY  AND  TECHNIQUES 


A.  GENERAL 

A  network  is  a  set  of  tasks  listed  in  the  sequence  in  which  they  are 
accomplished.  A  task  is  defined  as  a  requirement  for  resources  (men,  parts, 
equipment,  facilities)  needed  for  a  specific  time.  Tasks  have  a  sequential  or 
parallel  relationship,  as  defined  by  the  network,  to  each  other.  Figure  14  Is 
the  basic  network  terms  and  definitions.  Network  data  is  entered  on  Extended 
Forms  11. 

In  LCOM  modeling,  networks  are  divided  into  two  (2)  categories.  The 
first,  main  aircraft  servicing  networks,  apply  to  the  aircraft  in  general. 

These  networks  contain  such  tasks  as  towing,  preflight  inspection,  postflight 
inspections,  and  servicing  LOX/NITRO.  Reconfiguration  networks,  described  in 
the  previous  chapter,  are  also  considered  In  this  category.  The  other 
category  of  networks  are  the  corrective  maintenance  networks.  These  networks 
consist  of  the  scheduled  and  unscheduled  maintenance  actions  required  to  fix 
subsystems  of  the  aircraft.  These  categories  are  arbitrary  classifications 
useful  for  aircraft  data  structures.  There  is  no  such  limitation  in  LCOM.  The 
user  may  define  data  in  any  manner  to  suit  his  needs. 

B.  NETWORK  ENTRY 

During  the  simulation,  task  network  processing  is  started  by  defining  an 
entry  point  to  the  network  on  Form  17  or  Form  21.  When  a  mission  request  is 
filled,  the  aircraft  (or  other  resource)  filling  the  mission  will  process 
through  the  tasks  of  the  network.  The  processing  starts  at  the  entry  node  and 
ends  when  there  are  no  further  tasks  in  the  sequence.  The  aircraft  can  be 
thought  of  as  flowing  through  the  network,  obeying  the  selection  modes  at  each 
new  branch. 

C.  SELECTION  MODES 

The  processing  of  each  task  in  the  network  is  determined  by  a  selection 
mode  defined  in  the  input  data  which  may  specify  one  of  15  options.  These 
options  include  modes  A,  C,  D,  E,  F,  G,  H,  I,  J,  K,  L,  R,  S,  T  and  U.  These 
inodes  can  be  basically  subdivided  into:  those  that  are  discrete  functions 
(C,  D  and  R),  those  that  are  probabilistic  in  nature  (A,  E  and  G),  those  used 
to  control  mission  timing  within  the  modes  (S),  and  those  that  deal  with 
specific  model  features  (F,  H,  I,  0,  K,  L,  T  and  U). 

The  main  module  is  designed  to  permit  utilization  of  any  of  these  network 
selection  mode  options.  They  provide  the  desired  flexibility,  selection,  and 
control  of  the  scenario  chosen  by  the  user.  The  network  feature  of  the  main 
module  provides  a  means  for  simulating  a  large  variety  of  weapon  systems  and 
operational  environments. 

1.  DISCRETE  FUNCTIONS 

Discrete  functions  are  networked  using  C,  D  or  R  modes. 
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Figure  14.  Network  Terms  Definition. 


(a)  Mode  C  -  Network  Section  Selection  -  This  “C“  or  call  option 
permits  the  user  to  describe  the  task  network  in  sections.  This  eliminates 
duplicate  network  data.  The  call  section  can  be  called  from  any  place  in  the 
networks.  It  is  analogous  to  program  subroutines.  The  task  name  is  the  entry 
node  to  the  call  section.  The  simulation  will  look  for  this  node,  enter  that 
section,  and  then  perform  the  tasks  that  follow.  The  entire  call  section  will 
be  completed  and  then  the  aircraft  will  return  to  the  node  following  the  call 
section  and  continue  processing. 

Figure  15  is  an  example  of  the  “C"  selection  mode.  In  the  main  network 
shown  there  are  two  tasks  that  use  the  "C"  selection  mode;  INI  and  IN2.  When 
the  aircraft  hists  the  first  “CALL"  task,  it  will  go  to  CALL  Section  1,  Node 
INI  and  perform  the  task,  HTIRE.  After  completing  that  task,  the  aircraft  will 
return  to  the  main  network. 

After  the  aircraft  flies  its  sortie,  it  reaches  another  "CALL"  section, 
IN2.  The  aircraft  will  go  to  Node  IN2  and  perform  the  task  HGEAR.  After  HGEAR 
is  completed,  the  aircraft  will  go  to  INI  where  it  will  perform  the  task  HTIRE. 
After  HTIRE  is  completed  the  aircraft  will  return  to  CALL  Section  2,  Node  02, 
and  perform  the  task  HDOOR.  When  task  HDOOR  is  done;  CALL  Section  2  is 
completed;  the  aircraft  will  return  to  the  main  network  to  continue  processing. 
This  example  illustrates  that  CALL  sections  can  be  nested  within  other  CALL 
sections. 


MAIN  NETWORK 

//■ — Or 

CALL  SECTION  1 

(my™L 

Figure  15.  Example  of  C  Selection  Mode. 

(b)  Mode  0  -  "Do  the  Task"  -  This  option  is  used  when  there  is  no 
question  of  selection.  When  this  node  is  used.  It  means  no  criterion  is 
required  to  select  whether  or  not  the  task  is  done.  It  Is  always  done  when 
it  is  addressed  by  a  preceding  task. 

(c)  Mode  R  -  Resource  Availability  Mode  -  The  "R“  Selection  is  a 
decision  mechanism  that  determines  which  branch  of  a  network  will  be  processed 
according  to  the  availability  of  resources.  It  checks  each  "R"  coded  task  from 
the  same  prenode  in  the  sequence  listed  on  the  Forms  11,  and  processes  the 
first  one  that  has  the  necessary  resources  avallaDle.  If  no  task  can  be 
processed,  it  goes  back  to  the  first  task  and  waits  for  its  resources  to 
become  available.  No  further  search  is  done.  NOTE:  The  resources  checked  are 
only  those  requested  on  the  applicable  "R“  task. 

The  "R"  Is  needed  to  model  avionics  repair  on  new  generation  test 
equipment  where  there  are  primary /alternate  test  stations  for  each  LRU.  In  the 
example  of  Figure  16,  availability  of  the  primary  station  T1  is  checked  first. 


INI 


HTO. 
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A  dummy  task,  CHECK!,  is  defined  with  T1  as  a  resource.  If  T1  is  not  free, 

T2  is  checked.  If  T2  is  also  in  use,  the  LRU  will  wait  on  T1 .  When  T1  is 
available  the  CALL  section  checks  for  test  station  failure.  If  there  is  no 
failure,  the  LRU  repair  task  is  accomplished,  using  T1  as  a  task  resource. 

If  the  test  station  has  failed,  it  is  consumed  and  repaired.  The  "R" 
selection  mode  is  then  used  again  to  see  if  T2  is  free,  and  if  not,  waits  for 
the  repair  of  Tl. 

Consider  another  situation  where  a  large  aircraft  must  be  brought  into  a 
hangar  for  jacking  (See  Figure  17).  When  a  hangar  is  not  available  it  may  be 
jacked  outside,  provided  there  is  no  wind  and  good  weather.  The  first  task 
would  list  all  the  job  resources  plus  the  hangar,  while  the  second  would  be  a 
dummy  task  listing  job  resources,  but  no  hangar.  When  everything  was 
available  to  do  the  work  except  the  hangar,  the  second  branch  would  be 
selected,  allowing  the  probability  of  weather  to  determine  whether  the  job 
would  be  done  outside  or  waif  on  the  hangar.  A  more  sophisticated  approach 
would  schedule  good  weather  days  as  a  short  resource  on  the  Forms  16,  and 
list  the  good  weather  resource  as  a  task  requirement  on  the  second  branch. 

In  that  case  no  "E"  probabilities  would  be  required.  This  kind  of  modeling 
gimmickery  invites  errors  and  should  be  restricted  to  those  few  instances 
where  it  is  really  essential  to  the  objective  of  the  study. 

2.  PROBABILISTIC  FUNCTIONS 

The  probabilistic  functions  are  networked  using  an  "A",  "E"  or  "6"  mode. 

(a)  Mode  A  -  Nonmutually  Exclusive  Probability  -  This  "A"  or  “Any" 
selection  mode  is  the  option  used  to  select  none,  one  or  more  of  several 
parallel  branches  in  the  network,  each  of  which,  involves  an  independent 
probability  of  accomplishment.  The  selection  of  each  branch  is  done 
independently;  none,  one  or  more,  or  all  parallel  branches  might  be  taken. 
Since  probabilities  are  independent,  they  do  not  have  to  sum  to  any 
particular  value.  The  APROB  change  card  may  be  used  to  change  the  probability 
of  a  specific  "A"  Selection  Mode  branch  at  any  simulated  time. 

An  “A"  Mode  should  normally  be  used  in  parallel  with  either  a  "D"  or  an 
"E"  Selection  Mode.  If  an  "A"  Mode  is  used  by  itself,  or  in  parallel  with 
another  “A"  Mode,  there  is  a  possibility  that  the  aircraft  will  not  do  that 
task  and  stop  processing  at  that  point. 

Figure  18  shows  an  example  of  an  “A"  Selection  in  parallel  with  a  "D" 
Selection.  The  end-of -runway  check  will  always  be  done.  Ten  percent  (10%) 
of  the  time,  however,  the  ECM  pod  will  be  removed  as  well. 


End -of -Runway  Check 


Remove  ECM  Pod 


Figure  18.  A  Selection  Mode. 
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Figure  16.  R  Selection  Mode  -  Example  #1 . 


JACK  IN  HANGAR  IF  FREE. 


Figure  17.  R  Selection  Mode  -  Example  #2. 
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(b)  Mode  E  -  Mutually  Exclusive  Probability  -  This  "E"  or  "Either" 
Selection  Mode  is  the  option  used  to  select  only  one  of  several  possible 
parallel  tasks  in  the  network.  Since  the  probability  values  are  mutually 
exclusive,  all  possibilities  should  be  accounted  for  and  the  sum  of  the 
probability  values  from  the  same  node  must  sum  to  1.0.  A  Restriction  when 
using  this  mode  is  to  not  mix  two  sets  of  “E"  branches  emanating  from  the 
same  node.  The  EPROB  change  card  may  be  used  to  change  the  probability  of  a 
specific  "E"  Selection  Node  branch  at  any  point  in  time  during  the  simulation. 

Figure  19  shows  an  example  of  an  "E"  Selection  network.  From  the  entry 
node,  a  choice  of  one  task  or  the  other  will  be  made.  Seventy-five  (75%) 
percent  of  the  time,  a  "Remove-and-Replace"  action  will  be  done.  The  other 
twenty-five  (25%)  percent  of  the  time,  a  task  called  "Minor  Maintenance"  will 
be  done. 


Remove-and-Repl ace 
E.75 

Minor  Maintenance 


E  .25 


Figure  19.  E  Selection  Mode. 

(c)  G  Mode  -  Nonmutual ly  Exclusive  Probability  The  "G"  or  "Get"  at 
least  one,  selection  mode  is  the  same  as  the  "A"  Mode  wTth  a  slight 
modification.  Remember  that  when  processing  a  parallel  set  of  "A"'s,  the  rule 
is  that  any,  all  or  possibly  none,  of  the  branches  may  be  taken,  depending  on 
the  individual  random  numbers  drawn.  The  "G"  Selection  differs  in  two  (2) 
respects.  First,  if  these  same  "A"  tasks  were  instead  marked  "G"  and  none 
were  selected,  then  the  model  would  recycle  (take  another  set  of  random  draws) 
until  at  least  one  "G"  task  was  chosen.  Secondly,  the  "G"  Selection  Mode  is 
statistically  different  than  "A"  when  considering  the  independence  of  failures. 
The  probability  of  no  selection  is  zero  (0).  Use  of  the  "G"  Mode  will  increase 
simulation  run  time  (computer  time),  particularly  if  small  "G"  Selection 
parameters  are  used.  The  only  restriction  on  use  of  the  "G"  Mode  is  that  if  it 
is  used  at  a  particular  juncture/node,  then  aH  tasks  emanating  from  that 
juncture/node  must  also  be  "G"  Selection  Modes.  The  GPROB  change  card  may  be 
used  to  change  the  probability  branch  at  any  point  in  time  during  the 
simulation.  (3:  Appendix  H) 

Figure  20  shows  an  example  of  a  "G"  Selection  Network.  At  the  entry  node 
the  simulation  will  make  a  draw.  If  no  task  is  chosen,  draws  will  continue  to 
be  made  until  at  least  one  task  is  selected. 
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swmutiMUi 


TASK! 


V--/G.35 

TASK2 


G.25 

_ TASK3 

G.05 

Figure  20.  G  Selection  Mode. 

3.  CONTROL  MISSION  TIMING 

Mission  timing  control  is  networked  using  the  "S"  Mode. 

Mode  S  -  Sortie  Task  Timing  Control  -  This  "S",  or  "Sortie",  option  is 
assigned  tc  the  sortie  task,  a  task  whose  starting  time  and  duration  is 
controlled  by  the  mission  data  (AF  Form  2720  (Form  20)).  When  this  option  is 
encountered  on  a  task,  mission  data  is  used  to  establish  the  task  time 
(sortie  length).  There  should  only  be  one  sortie  task  (S  Mode)  in  a  main 
network . 

The  "S"  Mode  task  can  decrement  failure  clocks  by  flying  hours.  Be 
careful  when  decrementing  clocks  by  sortie  length.  If  you  have  more  than  one 
main  network  leading  to  a  sortie,  you  must  check  for  clock  failures  within 
each  network.  Failure  clocks  are  not  decremented  until  they  have  been 
referenced  within  the  network.  In  other  words,  no  failure  will  take  place 
unless  the  failure  clock  has  been  checked  before  enri-of-network. 

4.  SPECIFIC  MODEL  FEATURES 

Specific  model  features  can  be  networked  using  "F",  "H",  "I",  "J",  "K", 
"L",  "T"  and  "U"  Modes. 

(a)  F  Mode  -  Failure  Mode  Selection  -  This  "F"  or  "Failure"  option 
means  task  accomplishment  will  be  controlled  by  a  failure  clock  within  the 
network.  The  Failure  Clock  mechanism  represents  subsystem  malfunctions  that 
occur  on  aircraft.  Within  the  simulation,  it  indicates  when  tasks  following 
the  cloc'*  are  to  be  done. 

Figure  21  is  an  example  of  how  the  "F"  Selection  Mode  may  be  used. 

CALLS1  is  the  naming  convention  of  the  node  that  the  unscheduled  maintenance 
networks  are  tied  into.  The  numbers  after  the  "F"  Node  are  the  values  of  the 
failure  clocks.  When  these  clocks  are  decremented  to  zero  (0),  the  clock 
indicates  a  failure,  and  when  it  is  checked,  the  task  following  this  clock 
will  process.  A  discussion  of  the  failure  mechanism  follows: 
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SYSTEM  11 


F  65.0 
SYSTEM  12 


F  40.0 
SYSTEM  13 


F  30.0 


Figure  21.  F  Selection  Mode. 

The  methodology  for  inducing  resource  failure  into  the  simulation  is 
designed  to  provide  the  great ist  possible  flexibility  in  use  of  this  failure 
mechanism.  The  basic  mechanism  can  be  thought  of  as  a  clock  that  is  utilized 
to  trigger  action  within  the  network.  This  clock  is  first  set  to  some  value, 
a  random  variate  or  constant,  then  successively  decremented  by  defined  amounts 
when  processing  certain  network  tasks,  until  the  value  is  zero  (0).  Upon 
reaching  zero  (0)  a  failure  of  some  sort  has  occurred;  information  is  stored 
concerning  where  in  the  network  this  clock  was  referenced;  the  clock  is  reset  in 
a  manner  similar  to  the  original  setting;  and  later  successively  decremented  for 
the  next  failure.  Clocks  can  represent,  and  be  driven  by,  almost  an  failure 
criteria  such  as;  number  of  aircraft,  sortie  time,  resource  operating  time, 
absolute  time,  etc.;  limited  only  by  the  users'  ingenuity. 

Each  clock  is  defined  on  the  Extended  Form  11,  in  terms  of  its  mean, 
variance,  and  distribution  type.  Decrements  for  each  clock  must  also  be  provided 
on  the  Extended  Form  11.  The  model  uses  these  parameters  to  initially  set  and 
reset  the  clocks.  With  the  exception  of  the  triangular  distribution,  all 
standard  and  empirical  distributions  can  be  used. 

Clocks  are  used  within  the  networks  by  specifying  an  "F"  Selection  Mode  and 
using  the  clock  as  the  parameter.  The  user  can  use  a  clock  with  an  "F"  selection 
parameter  in  more  than  one  place  in  the  network'.  When  a  clock  reaches  zero  (0), 
information  about  all  the  locations  in  the  network  concerned  with  the  clock  are 
used  to  control  the  network  processing.  This  information  is  provided  to  the 
resource  whose  network  processing  caused  the  clock  or  clocks  to  breach  (fail). 

To  decrement  the  clocks,  the  task  name  used  to  decrement  must  be  specified 
on  the  Form  14.  The  Form  14  lists  all  the  clocks  in  the  model,  the  decrement 
mode,  and  the  value  of  the  decrement.  Any  desired  combination  of  failure 
setting  and  decrementing  can  be  included  in  a  simulation,  such  as  listing  the 
same  failure  clock  under  two  different  decrement  tasks  and  values.  However,  tasks 
can  only  be  identified  once  on  the  Form  14  and  can  only  decrement  by  one  mode. 

Another  application  of  the  "F"  Selection  Mode  is  to  control  network 
processing  (F  task  stringing).  "F"  task  stringing  Is  defined  as:  Sequential 
tasks  in  the  network  being  controlled  by  the  same  clock. 

To  further  understand  the  use  of  this  method  of  controlling  network 
processing,  let  us  consider  the  requirement  of  unloading  an  aircraft's  munitions 
and  then  parking  it  in  a  shelter  to  perform  unscheduled  or  phase  (scheduled) 
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maintenance.  This  is  especially  important  when  a  surge  condition  is  modeled 
with  a  "Quickturn"  methodology.  (The  aircraft  flies  a  sortie,  and  is 
immediately,  unless  broken,  processed  for  another  sortie.) 

In  Figure  22,  a  “CALL"  is  made  to  an  unscheduled  maintenance  check.  The 
aircraft  will  enter  into  the  network  entry  node,  CALUM.  The  simulation  will 
skip  over  the  UNLOAD  and  SHELTR  task  and  then  check  the  unscheduled  (tied  to 
node  CALLS1)  and  phase  (tied  to  node  CALPHAS)  failure  clocks.  (The  "X"  in  the 
selection  mode  is  used  on  the  Extended  Form  11  to  indicate  "F"  task  stringing.) 
If  a  clock  has  breached  (failed),  the  aircraft  will  go  back  and  process  the 
UNLOAD  and  SHELTR  tasks,  otherwise,  it  will  return  to  the  main  network  and  be 
released  to  the  aircraft  pool  in  its  post-sortie  configuration. 


Figure  22.  F  Task  Stringing. 


Figure  23  is  a  listing  of  four  other  examples  of  "F"  task  stringing.  It 
gives  the  "do's"  and  "don't's"  of  "F"  task  stringing.  Another  application  of 
failure  clocks  is  multiple  locations  controlled  by  the  same  clock. 

Figure  24  illustrates  the  use  of  this  feature.  Suppose  an  aircraft 
normally  used  an  on-board  APU  (Auxiliary  Power  Unit)  for  starting,  but  could  be 
started  with  an  MA-1A  (ground  starting  unit)  if  the  APU  failed.  A  pre-sortie 
call  section  would  Include  the  decrement  and  an  "F"  task  for  the  APU  clock, 
followed  by  tasks  to  get  an  MA-1A  and  start  the  engines.  The  post-sortie 
unscheduled  maintenance  call  section  should  Include  an  identlcial  "F"  task 
followed  by  tasks  to  fix  the  APU.  Whenever  the  APU  decrement  failed  the  clock 
at  aircraft  starting,  both  "F"  tasks  would  be  triggered.  LCOM  would  allow  the 
aircraft  to  be  started  by  the  HA-1 A,  but  APU  repair  would  be  deferred  until 
picked  up  after  the  flight.  Each  clock  name  should  only  be  used  for  one  "F" 
task  in  the  LCOM  data  base  unless  this  feature  is  specifically  desired. 
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EXAMPLE  1 

In  this  example,  the  FLOWQ  contains  data  to  control  network  processing  triggered  by 
a  failure  of  CLOCKA.  Segments  10  and  20  are  controlled  indirectly  by  this  clock  as 
they  are  coded  F  selection  mode  and  lead  directly  to  network  segment  30.  Set  FLOWQ 
contains,  a  30,  20,  and  10.  If  CLOCKB  had  failed  and  the  FLOWQ  would  contain  25,  20 
and  10.  If  both  had  failed  the  FLOWQ  would  have  contained  30,  25,  20,  and  10  (no 
duplicates) . 

5  Network  segments  are  placed 

/s- . .  in  FLOWQ  of  Aircraft 


25 

^  (CLOCK-B) 

l  30 

F  (CLOCK-A) 


FLOWQ  entries 
when  Clock-A 
fails 


EXAMPLE  2 

F  stringing  will  not  happen  between  network  section.  In  this  example,  these  two  Fs 
will  not  string  when  Clock-C  fails.  FLOWQ  only  contains  a  20. 

10  |  A  - 

— - - - -  V-/F  (CLOCK-C) 


EXAMPLE  3 

F  stringing  will  be  accomplished  thru  all  proceeding  F  tasks,  even  those  with 
valid  parameters. 

Clock-E's  failure  stringing  will  include  segments  40,  30,  20,  and  10  in  the  FLOWQ. 
Clock -O' s  failure  stringing  will  include  segments  30,  20,  and  10  in  the  FLOWQ. 


(CLOCK-D) 


F  (CLOCK-E) 


EXAMPLE  4 


Two  F  segments  in  parallel  cannot  lead  to  a  single  F  segment  controlled  or 
uncontrolled  because  the  model  has  no  way  of  knowing  which  way  to  string  back. 
Therefore,  this  networking  is  illegal . 


F  (CLOCK) 


NOTE:  All  numbers  in  the  above  networks  represent  network  segment  locations,  not 
task  numbers. 
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Figure  24.  F  Selection  Mode  -  Multiple  Failure  Clocks 


(b)  H  Mode  -  Halt  Mechanism  Controlled  -  The  "H"  or  "HALT"  Mode  acts 
like  the  "F"  Mode  except  in  the  reverse.  If  a  HALT  clock  has  breached  for  a 
particular  "H"  task,  the  processing  of  that  particular  task  and  the  subsequent 
network  tasks  will  HALT  at  that  point. 

The  HALT  clock  is  a  network  gate  that  operates  as  a  mirror  image  of  a 
failure  clock.  It  normally  remains  open  and  allows  tasks  to  process  through 
it.  When  a  "failure"  occurs,  it  closes  the  gate  and  eliminates  the  requirement 
to  process  the  following  tasks.  The  HALT  clock  is  then  reset  into  an  open 
position  until  the  next  failure  occurs.  Forms  14  are  used  to  specify 
decrements  for  HALT  clocks  in  the  same  way  as  for  failure  clocks.  (NOTE:  The 
phase  program  generates  a  decrement  of  1.0  for  HALT  clocks  on  the  Form  14s.) 

The  task  name  on  the  HALT  clock  should  be  different  from  any  failure  clock. 

Consider  the  "H"  as  a  failure  generated  stopping  point  in  a  particular 
leg  of  the  network  being  processed.  As  implied  here,  the  "H"  Selection  is 
handled  by  the  user  just  like  the  "F"  with  one  exception;  "H"  tasks  must  be 
independent  of  each  other;  that  is  every  "H"  Selection  Mode  must  have  an  "H" 
clock  associated  with  it.  This  ensures  that  "H"  tasks  will  not  be  strung 
together  like  "F"  tasks.  (No  stringing  of  "Hs"  with  "Fs"  or  other  "Hs"  is 
permitted.) 

HALT  clocks  are  useful  for  modeling  "if"  conditions.  As  in  Figure  25, 
suppose  a  C-130  aircraft  is  to  divert  to  a  Remotely  Piloted  Vehicle  (RPV) 
recovery  site  when  at  least  two  (2)  recovered  RPVs  are  ready  for  pickup,  but 
proceeds  directly  back  to  home  base  otherwise.  Resource  RPVR  represents  a 
recovered  RPV  at  the  recovery  site.  A  HALT  switch  can  be  set  up  with  parallel 
decrements  and  HALT  clocks.  One  branch  tries  to  consume  two  RPVs  (Note  that 
this  must  be  within  a  call  section  to  prevent  the  subsequent  network  from 
being  processed  twice.).  The  second  branch  has  a  time  delay  followed  by  a 
decrement.  If  the  consumes  are  not  done  within  this  time,  a  HALT  clock  is 
triggered  on  the  first  branch  to  stop  further  processing.  The  aircraft 
proceeds  directly  back  to  home  base  on  branch  two  (2).  It  also  generates  two 
(2)  RPVs  to  clear  the  consume  task  on  branch  one  (1),  and  returns  the  stock  of 
RPVs  waiting  airlift  back  to  the  original  level. 

If  the  two  (2)  RPVs  were  immediately  available,  the  aircraft  would 
process  along  the  first  branch  and  trigger  a  HALT  on  branch  two  (2).  The 
\  tasks  would  involve  landing,  loading,  launch,  fly,  land,  unload,  generate 
resources  to  represent  RPVs  at  home  station,  and  post-sortie  maintenance  and 
service  on  the  aircraft  and  RPVs  at  home. 

(c)  I  Mode  -  Cannibalization  Data  Mode  -  The  "I"  or  “Ignore", 

Selection  Mode  is  used  in  conjunction  with  the  cannibalization  mechanism.  It 
Is  used  only  on  tasks  that  consume  a  part  and  Indicate  to  the  cannibalization 
mechanism  that  the  part  being  consumed  should  be  included  in  the  list  of 
cannibalized  parts.  It  also  tells  the  normal  processing  to  ignore  the  task 
time  when  the  part  is  received  from  supply. 

The  purpose  of  the  cannibalization  feature  is  to  obtain  aircraft  for  a 
mission  at  FRAG  time  through  a  cannibalization  action,  when  the  on-hand 
balance  of  the  aircraft  is  less  than  the  minimum  required.  Several  items  work 
together  to  control  the  use  of  this  feature. 
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Figure  25.  H  Selection  Mode. 


The  CANSWT  change  card  is  used  to  enable  the  feature  (CANSWT  =1,  ON)  o\ 
disable  it  (CANSWT  =0,  OFF).  The  user  must  set  the  CANSWT  “ON"  or 
cannibalization  will  not  take  place.  (Default  for  CANSWT  is  zero  (0).) 

Cannibalization  cannot  cake  place  unless  the  UI"  Selection  Mode  task  is 
used.  The  "I"  Mode  specifies  those  tasks  containing  part  consumptions  that 
can  take  advantage  of  cannibalization. 

The  "I"  Mode  also  indicates  that  the  time  specified  is  a  cannibalization 
removal  time.  During  normal  processing  where  the  part  is  obtained  from  supply 
(on-hand  quantity  is  greater  than  zero  (0))  the  time  is  to  be  ignored. 

However,  if  the  part  is  unavailable  from  supply,  the  task  would  be  backordered 
and  the  aircraft  would  probably  be  NMCS  (Not  Mission  Capable  Supply).  If  the 
demand  for  this  part  is  to  be  satisfied  by  another  cannibalization  action,  the 
time  and  manpower  resources  specified  on  the  "I"  Mode  task  would  be  used. 

When  activated,  cannibalization  reviews  all  in-use  aircraft  to  qualify 
them  as  candidate  donors  or  candidate  acceptors.  Only  NMCS  aircraft  can  be 
considered  as  either  donors  or  acceptors.  Given  that  the  donors  and  acceptors 
are  qualified,  the  Main  Module  then  determines  if  the  manpower  resources  on 
the  "I"  Mode  task  are  available.  If  so,  and  donors  and  acceptors  are  matched 
up,  the  Main  Module:  (1)  simulates  the  removal  of  the  part  from  the  donor, 

(2)  dedicates  the  part  to  the  acceptor,  (3)  delays  the  processing  of  the 
acceptor  part  demand  task  until  the  part  is  available,  and  (4)  establishes  a 
like  demand  for  the  part  on  the  donor  aircraft  (  a  copy  of  the  acceptor  network 
from  the  "I"  Mode  task  to  the  end  of  the  network  is  filed  against  the  donor 
aircraft.). 

Other  external  controls  are  available  to  the  user.  The  maximum  number  of 
part  demands  for  acceptor  aircraft  that  can  be  satisfied  by  cannibalization  has 
a  default  of  two  (2).  Also  the  maximum  number  of  holes  on  (parts  obtained  from) 
a  donor  aircraft  that  can  be  made  through  cannibalization  has  a  default  of  five 
(5).  The  CANNIB  change  card  allows  the  user  to  change  these  quantities,  by 
aircraft  type. 

The  user  may,  in  this  network,  control  where  he  wants  a  part  consumption 
task  considered  for  cannibalization  action  by  use  of  the  "1“  Selection  Mode  as 
previously  described.  Use  of  the  "D"  Select  Mode  where  you  never  want 
cannibalization  to  occur. 

There  can  be  only  one  of  a  particular  part  cannibalized  at  a  time  for  a 
particular  aircraft.  If  more  than  one  demand  for  a  part  is  backorder,  all 
demands  except  the  last  must  be  satisfied  before  cannibalization  may  be  used. 

Figure  26  is  a  summary  of  the  rules  for  cannibalization. 

(d)  T  Mode  -  Trigger  Node  Controlled  -  This  "T",  or  "Trigger",  Selection 
Mode  is  used  for  the  configuration  management  of  internal  equipment  on  an 
aircraft.  It  is  treated  as  a  DO  task  for  network  processing  purposes,  but  will 
trigger  either  the  loss  or  gain  of  some  internal  piece  of  equipment.  (NOTE: 

When  dealing  with  parallel  branches,  only  one  (1)  "T"  can  be  used  and  it  must 
occur  first  in  the  Form  11s.)  Please  refer  to  Section  III,  the  "Internal 
Configuration"  sub  section,  for  a  more  detailed  explanation  of  this  selection 
mode. 
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THE  RULES  GENERATING  THE  USE  OF  CANNIBALIZATION 


1.  CANSWT  (Simulation  Change  Card)  must  be  set  to  one  (1). 

2.  “I"  selection  mode  must  be  used  on  tasks  with  a  part  consumption  to  be 
considered  for  cannibalization. 

3.  Only  a  single  part  consumption  and  men  resources  are  permitted  on  an  "I" 
mode  task. 

4.  If  the  "I"  mode  is  used,  the  task  time  is  always  ignored  except  during 
cannibalization. 

5.  If  the  UI"  mode  is  used  on  a  task  without  a  consume  on  it,  the  Input 
module  assumes  the  mode  is  “D"  (DO),  makes  the  substitution,  gives  a  message, 
and  continues. 

6.  The  CANNIB  change  card  can  reset  the  maximum  number  of  parts  to 
cannibalize  for,  and  the  maximum  number  of  “holes"  permitted  on  an  aircraft 
(DONOR)  caused  through  cannibalization. 

7.  Acceptor  Aircraft  -  Aircraft  which  satisy  the  following  conditions  are 
set  up  as  candidate  acceptor  aircraft. 

a.  No  scheduled  or  unscheduled  jobs  are  in  process. 

b.  At  least  one  part  is  backordered. 

c.  Only  parts  are  backordered. 

J.  Aircraft  in  post  sortie  or  activity  processing. 

e.  Tasks  backordered  and  eligible  for  receiving  a  cannibalized  part 
must  be  only  jobs  backordered  for  the  aircraft. 

f.  The  number  of  tasks  backordered  and  eligible  for  receiving  a 
cannibalized  part  must  be  liss  than  or  equal  to  a  limit  determined 
by  the  user. 

g.  The  aircraft  cannot  be  waiting  for  dedicated  parts  from  a  previous 
cannibalization  action  (be  a  current  acceptor). 

h.  The  aircraft  cannot  have  an  In-process  donation  to  another  aircraft 
(be  a  current  donor). 


Figure  26.  Rules  for  Cannibalization  -  I  Selection  Mode. 


40 


THE  RULES  GENERATING  THE  USE  OF  CANNIBALIZATION  (Continued) 


8.  Donor  Aircraft  -  Aircraft  which  satisfy  the  following  conditions  are  set 
up  as  candidate  donor  aircraft: 

a.  No  scheduled  or  unscheduled  jobs  are  in  process. 

b.  At  least  one  part  backordered. 

c.  Only  parts  are  backordered. 

d.  Number  of  jobs  backordered  plus  in-process  removals  must  be  less  than 
the  maximum  number  of  holes  (limit)  permitted  on  the  aircraft. 

e.  Cannot  be  waiting  for  dedicated  parts  from  a  previous  cannibalization 
action  (be  a  current  acceptor). 

f.  Must  be  post-sortie  or  activity  processing  or  an  aircraft  pre-sortie 
processing  whose  mission  has  flown  or  cancelled. 


FIGURE  26.  Rules  for  Cannibalization  -  I  Selection  Mode  (concluded) 
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(e)  J,  K  and  U  Modes  -  Aircraft  Timing  Switches  -  The  "J",  or  “Jump", 
Selection  Mode  is  used  to  partially  activate  the  "Aircraft  Timing  Switch". 

The  "K"  or  "Kill",  Selection  Mode  is  used  to  fully  activate  the  "Aircraft 
Timing  Switch". 

The  "U",  or  “Unschedule  and  Unset"  Mode  is  used  to  deactivate  the 
"Aircraft  Timing  Switch"  after  it  has  been  fully  turned  on  and  a  reset  for  it 
has  been  scheduled. 

The  Aircraft  "K"  Selection  Mode  timing  switch,  KTIMSW,  controls  the 
processing  (or  not  processing)  of  network  tasks  coded  with  a  "J"  or  "K" 
Selection  Mode. 

The  primary  control  of  the  setting  and  resetting  of  this  switch  is  done 
by  tasks  coded  with  a  "K"  Selection  Mode.  A  Secondary  Control  for  resetting 
the  switch  is  done  by  tasks  coded  with  a  "U"  Selection  Mode.  The  switch  is  a 
three  (3)  position  switch  (off  =  0,  partially  on  =1,  fully  on  *  2). 

When  the  switch  is  off,  or  partially  on,  both  "J"  and  "K"  Selection  Mode 
tasks  are  processed.  When  fully  on,  these  tasks  are  skipped.  The  partially 
on  condition  permits  users  to  process  series  of  "J"  Mode  tasks,  even  with 
intervening  tasks  using  other  selection  modes.  These  "J"  tasks  will  set  the 
switch  to  partially  on. 

"K"  tasks,  however,  will  set  the  switch  fully  on,  regardless  of  the 
current  switch  condition,  and  trigger  the  simulation  software  to  reset  the 
switch  to  off  after  a  specified  time  interval.  This  triggering  of  the  reset 
is  done  at  the  beginning  of  the  “K"  task,  prior  to  processing  it.  The  time 
interval  is  by  aircraft  type  and  defaults  to  24  hours.  However,  the  user  may 
use  the  KTIMSW  change  card  to  input  a  new  time  interval. 

If  the  user  fails  to  control  the  switch  with  a  "K"  Mode  task,  the 
simulation  software  will  take  some  default  actions  at  End -of -Network.  End- 
of-Network  (EON)  is  defined  as  the  end  of  network  processing,  that  is,  the 
last  task  completion.  This  can  occur  at  either:  (1)  true  End-of -Network,  (2) 
at  the  sortie  task  for  a  spare  aircraft,  or  (3)  at  the  sortie  task  for  an 
aircraft  whose  mission  has  already  occurred  or  been  cancelled.  If  at  least 
one  "0"  Mode  task  was  processed  and  the  switch  was  partially  on  when  reached, 
the  switch  would  automatically  be  set  fully  on  and  the  software  triggered  to 
reset  the  switch  to  OFF  after  the  specified  time  interval.  With  the  switch 
either  ON  or  OFF  at  EON,  no  action  is  taken. 

The  "U"  Selection  Mode  is  effective  only  if  the  switch  is  fully  on  and  a 
reset  of  it  has  been  triggered.  The  "U"  Selection  Mode  will  unschedule  the 
switch's  resetting  and  set  it  off  immediately  upon  being  processed.  If  the 
switch  is  off,  or  partially  on,  when  the  "U"  Selection  Mode  is  processed,  no 
action  is  taken.  In  all  cases,  the  task  coded  with  the  "U"  Mode  will  be 
processed  as  a  "DO"  task. 

The  KTIMSW  can  be  used  in  either  pre-  or  post-sortie  networks.  However, 
there  is  only  one  (1)  "K"  timing  switch  per  aircraft.  Once  the  "K"  Mode  task 
has  been  processed,  all  subsequent  "0"  or  "K"  Mode  tasks  in  the  network  will 
not  be  processed  unless  the  reset  time  interval  has  passed  or  a  "U"  Selection 
Mode  task  has  been  processed.  Therefore,  use  of  the  feature  in  pre-sortie 
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could  negate  post-sortie  use. 

RAM  aircraft  are  returned  to  the  simulation  with  the  switch  turned  off  and 
no  switch  resetting  scheduled.  New  aircraft  enter  the  simulation  in  the  same 
manner . 

Figure  27  contains  a  total  recap  of  all  "K"  timing  switch  (KTIMSW)  actions 
that  can  take  place. 

(f)  L  Mode  -  Resource  Substitution  by  Location  -  This  is  a  relatively 
recent  addition  to  the  LCOM  software.  The  "L"  or  "Location"  Selection  Mode 
triggers  a  change  in  the  location  of  a  resource  that  is  processing  through  the 
network.  An  "L"  segment  will  have  a  parameter  which  specifies  the  location  to 
transfer  the  resource  to.  (Multiple  locations  are  allowed.) 

Resource  substitution  by  location  provides  the  capability  to  use  separate 
pools  of  similar  resources  to  process  a  network  of  tasks  through  separate 
locations,  without  the  requirement  to  define  duplicate  tasks  and  networks  for 
each  location.  For  example,  a  task  requiring  a  crew  chief  could  be  defined 
only  once,  be  called  from  a  network  processing  three  (3)  different  locations 
(such  as  different  bases),  and  the  software  will  use  the  crew  chief  from  the 
appropriate  location  to  process  the  task  at  each  location. 

The  basic  design  of  the  resource  substitution  by  location  feature  involved 
identifying  resources  to  specific  locations  and  using  a  new  selection  mode  "L" 
in  the  Form  11s  to  indicate  a  move  in  the  networks  from  one  location  to  another. 

An  example  of  this  capability  is  reflected  in  Figure  28.  A  mission  network 
beginning  at  node  "A"  will  be  processed  and  result  in  a  multiple  base  (location) 
situation.  Note  that  the  fuel  and  repair  tasks  in  the  network  section  beginning 
with  node  "F"  is  processed  at  (called  from)  the  three  (3)  different  locations. 
Each  of  these  two  (2)  tasks  will  have  only  a  single  definition  on  Form  12, 
requiring  a  MAN-A  and  MAN-B  respectively.  Also,  network  call  section  "F"  need 
only  be  defined  once.  However,  MAN-A  and  MAN-B  must  be  defined  on  Form  13  for 
each  location  they  will  be  used  at.  Also,  selection  mode  "L"  must  be  used  to 
identify  the  new  locations. 

The  use  of  the  Resource  Substitution  by  Location  feature  involves  the 
following  actions: 

(1)  All  resource  ID  names  other  than  clock  names  can  be  a  maximum 
of  only  five  (5)  characters  rather  than  the  six  (6)  characters  used  on  LCOM  II 
Version  3.5.  The  basic  design  involves  using  the  sixth  position  of  any  resource 
ID  field  (or  aircraft  name  field)  on  Forms  13,  16,  17,  20  or  22  to  only  specify 
the  location  to  which  the  resource  belongs.  Any  letter,  number,  or  symbol  can 
be  used  to  identify  a  particular  location.  The  default  location  is  signified  by 
a  blank  in  the  location  column.  This  enables  data  bases  to  run  through  this 
version  of  LCOM  easily,  even  if  only  one  (1)  location  is  being  considered,  by 
ensuring  that  all  NONCLOCK  resources  have  a  maximum  length  of  five  (5) 
characters  and  leaving  all  location  columns  blank.  Form  12  will  never  contain 
location  information  in  the  resource  ID  fields. 

(2)  The  location  specified  on  the  Form  20  for  the  resource 
entering  the  network  Is  the  location  from  which  the  Main  Module  will  Initially 
obtain  resources  by  the  network  tasks.  Whenever  a  task  starts,  the  Main  Module 
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Figure  27.  KTIMSW  Action  Matrix. 
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Figure  28.  Example-Resource  Substitution  by  Location. 


searches  for  the  resources  required  on  the  task,  based  on  the  location 
currently  in  effect.  The  location  can  be  changed  through  the  use  of  the  new 
selection  mode  "l"  in  the  Form  11s.  When  the  resource  processing  through  the 
network  is  to  move  a  new  location,  use  the  "L"  Selection  Mode  (which  is 
treated  like  a  ("D")),  and  specify  the  new  location  in  the  selection  parameter 
field.  The  Main  Module  will  then  obtain  resources  for  tasks  from  the  new 
location's  resource  pools. 

(3)  Any  resource  processing  through  the  network  other  than  an 
aircraft  is  released  to  the  pool  of  resources  of  the  location  in  effect  at 
end-of-..<itwork.  Currently,  aircraft  of  the  same  name  at  different  locations 
are  treated  as  different  aircraft  types  so  the  Main  Module  will  (at  end-of- 
network)  return  aircraft  to  the  pool  they  came  from.  This  also  means  that  the 
aircraft  specified  on  a  Form  20  must  include  the  same  location  that  was 
specified  on  the  Form  17  in  the  aircraft  name  field  for  this  Form  20's  mission 
or  activity  name. 

(4)  One  of  the  primary  aims  of  this  feature  is  to  minimize  the 
number  of  Form  11s  and  12s  needed  to  simulate  a  multi -location  situation. 
However,  a  Form  13  must  be  supplied  for  every  aircraft  or  non-aircraft  resource 
at  every  location  the  resource  might  be  used,  consumed,  generated  or  released. 
The  Main  Module  will  abort  with  a  fatal  message  if  any  needed  Form  13s  are  not 
present.  The  input  Module  does  provide  a  table,  listing  resources  versus 
location,  where  one  can  easily  tell  which  resources  have  been  defined  for  which 
locations. 


(5)  If  any  tasks  ar .  still  in  process  or  waiting  to  be  done  when 
a  "L"  is  encountered  in  the  network,  the  Main  Module  will  issue  a  message  and 
then  wait  to  process  the  "L"  until  all  other  branches  have  reached  end-of- 
network . 


(6)  Task  specific  substitutes  (12A  Records  on  Form  12)  can  come 
only  from  the  current  location,  but  the  general  substitutes  (Form  13)  include 
a  location  column  to  allow  substitution  between  locations. 

(7)  At  frag  time  only  aircraft  of  the  same  type  as  the  entering 
aircraft  and  at  the  same  location  as  the  entering  aircraft  will  be  considered 
for  cannibalization. 

There  is  no  direct  interface  between  the  general  and  task  specific 
resource  substitution  features  and  the  resource  substitution  by  location 
feature,  other  than  the  initial  application  of  the  location  to  the  initial 
resource  identification. 

Aircraft  are  not  the  only  resource  that  can  change  location.  For 
instance,  you  could  change  the  location  of  a  part  so  that  it  could  be  repaired 
at  another  location.  However,  if  it  is  not  transferred  back  to  the  original 
location,  the  part  will  become  one  of  the  available  resources  of  the  second 
location  once  it  is  fixed.  A  part  won't  transfer  back  to  the  original  location 
like  an  aircraft  does. 

D.  SHIFT  CHANGE  POLICIES  -  LCOM  FORM  1*  (AF  Form  2716) 

A  lot  of  flexibility  has  been  built  into  the  LCOM  Form  16s  (See  Figure  29). 
You  can  make  the  shift  patterns  as  simple  or  as  compllceted  as  you  desire.  The 
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normal  output  from  the  PHASE  Programs  creates  three  eight -hour  shift  patterns 
for  each  AFSC  with  200  men  authorized  on  each  shift.  This  is  referred  to  as 
unconstrained  manpower  because  you  probably  would  never  need  200  men  on  each 
shift. 

If  you  were  developing  an  LCOM  Model  in  which  the  first  five  days  is  a 
surge  (Maximum  effort  at  the  outbreak  of  hostilities)  then  transition  to  a 
sustained  combat  environment,  you  may  want  to  specify  12 -hour  shifts  for  the 
first  5  days  and  then  three  eight -hour  shifts  each  day  for  the  remainder  of 
the  simulation. 

If  you  were  modelling  a  peacetime  situation,  you  may  want  to  model  such 
situations  as  half  of  the  men  in  the  shop  going  to  lunch  for  an  hour.  Or  you 
may  want  to  model  peaks  in  manpower  at  shift  change  time  caused  by  men 
reporting  to  work  one-hour  before  their  shift  actually  starts.  You  may  also 
want  to  define  additional  shifts  to  account  for  a  "skeleton  crew"  on  the  job 
during  the  weekend. 

The  following  (See  Figure  29)  is  an  actual  case  illustrating  the  peacetime 
situation  described  above.  AFSC  325X0  has  two  men  working  from  midnight  to 
0800,  two  men  working  from  0800  to  1600  and  four  men  working  from  1600  to  2400 
daily.  A  skelton  crew  of  one  man  on  each  shift  is  working  on  the  weekends. 

A  total  of  14  shifts  are  defined.  The  first  12  shifts  are  repeated  daily 
for  five  days  then  the  last  two  shifts  are  repeated  daily  for  two  days.  The 
number  of  men  on  the  second,  sixth  and  tenth  shifts  are  cut  in  half  to 
simulate  each  half  of  the  shop  going  to  lunch  for  one  hour.  The  number  of  men 
on  the  fourth,  eighth  and  twelfth  shifts  simulate  the  shift  overlap.  The 
thirteenth  and  fourteenth  shifts  simulate  the  weekend  skelton  crew. 
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Figure  29.  Shift  Change  Policies  -  I.C0M  Form  16 


SECTION  VI 


NETWORKING 


A.  GENERAL 

The  procedures  to  be  used  In  defining  task  names,  using  LCOM  prefixes, 
node  names,  clock  names,  resource  definitions  and  some  general  guidance  in 
LCOM  networking  will  be  discussed  in  this  section.  These  coding  and  networking 
conventions  will  be  followed  when  applicable  regardless  of  which  data  processing 
programs  are  used  to  analyze  and  compile  maintenance  data  collection  data. 

Figures  30  and  31  give  examples  of  basic  network  logic. 

a.  Task  Names: 

(1)  Task  names  for  scheduled  maintenance,  and  tasks  that  take 
place  on  the  flightline  that  are  not  related  to  a  Work  Unit  Code  (WUC)  will 
consist  of  a  one  (1)  digit  LCOM  action  code  prefix  and  a  descriptive  abbreviation 
of  the  action  being  performed.  However,  those  tasks  that  can  be  described  very 
clearly  with  six  (l’>)  characters  or  less  need  not  have  the  LCOM  action  prefix. 

For  example,  preflight  could  be  "PREFLT",  aircraft  fueling  could  be  "FUEL",  and 
the  aircraft  sortie  could  be  "SORTIE".  Scheduled  time  change  removals  should 
utilize  the  unscheduled  removal  task  name,  or  carry  an  "S"  in  the  last  position 
if  different  time  or  resources  are  required.  Where  the  scheduled  maintenance 
task  corresponds  directly  with  a  special  inspection  (04000  series  WUC)  that  code 
should  be  used  in  place  of  a  descriptive  task  name. 

(2)  Phase  tasks  will  be  coded  with  the  prefix  PH.  When  networked 
by  phase,  tasks  will  be  coded  to  reflect  the  number  of  the  phase  and,  when  used, 
the  phase  card  being  checked.  For  example,  work  to  perform  the  phase 
inspections  of  card  23  in  phase  4  would  be  coded  PH0423,  PH  for  phase  inspection, 
04  for  phase  4,  and  23  for  card  23.  Common  phase  tasks  should  be  prefixed  with 
PH  followed  by  a  short  description  of  work  being  done,  for  example,  "PHPREP" 
could  represent  preparation  of  aircraft  going  into  phase. 

(3)  Task  names  for  unscheduled  maintenance  should  consist  of  an 
LCOM  action  code  followed  by  the  WUC.  The  last  position  of  the  task  name  may  be 
used  to  further  identify  tasks  when  networking  at  the  three  (3)  or  four  (4)  digit 
WUC  level.  For  example,  if  there  were  two  (2)  basic  remove  tasks  shown  on  the 
aircraft  for  the  71200  WUC  area  (perhaps  performed  by  different  specialists)  one 
would  be  coded  R71200  and  the  other  R71201. 

(4)  LCOM  Action  Codes:  (Reference  Figures  30  and  31  for  a 
schematic  example  of  LCOM  action  codes  and  networking). 

(a)  Standard  LCOM  action  codes  for  on-equipment  networks: 

F  =  Failure  Clock 

T  =  Troubleshoot 

X  =  Work  to  facilitate  maintenance,  (including  Access, 
Jacking,  etc.) 

A  *  Get  and  Hook  Up  Aerospace  Ground  Equipment  (AGE  or 
support  equipment) 
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Figure  30.  Schematic  of  Maintenance  Network  Basic  Logic. 
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Figure  31.  Schematic  of  Engine  Network. 


R  =  Remove  and  Replace  Component 
H  =  Inspection 
M  =  Repair  (on  aircraft) 

V  *  Verify  System  Works 

J  =  Aircraft  Handling  (towing,  etc.) 

C  =  Call  Section 
0  =  Decrement  Failure  Clock 
B  =  Loading/Downloading 
Z  =  Fly  Sortie 

Q  =  Draw  Component  from  Supply  or  Cannibalize 

(b)  Standard  LCOM  Coding  for  in-shop  work: 

L  =  Component  Identification 
W  *  Check  and  Repair  of  a  Component 
K  =  Check  OK 

N  =  Check  and  Not  Reparable  This  Station  (NRTS) 

Condemn  [now  referred  to  as  Not  Mission  Capable 
Supply  -  NMCS] 

Y  =  Disassemble/Reassemble 

(5)  To  enable  proper  compilation  of  statistics  in  the  simulation, 
one  of  seven  codes  are  used  to  designate  each  task  in  the  network.  These  Task 
Type  Codes  are  input  on  the  Form  2719  (Extended  Forms  11),  or  on  the  Form  2712 
(Forms  12).  These  Task  Types  are: 

Type  1  -  Used  to  designate  a  sortie  task. 

Type  2  -  Used  to  designate  a  task  that  involves  unscheduled 
maintenance. 

Type  3  -  Used  to  designate  a  task  that  involves  scheduled 
maintenance. 

Type  4  -  Used  to  define  the  first  depot  repair  task  in  the 
parts  network.  This  should  be  the  first  task  after 
leaving  the  base,  normally  the  order  and  ship  delay 
task.  This  task  type  is  equivalent  to  Type  2  except 
that  it  Is  needed  to  produce  post  processor  data  and 
ensure  the  shop  repair  and  the  Not  Reparable  This 
Station  (NRTS)  statistics  in  the  Performance  Summary 
Reports  (PSR)  are  correct. 

Type  5  -  Used  for  other  tasks,  such  as  delays.  The 

statistics  for  these  tasks  are  not  accumulated. 


Type  6  -  Used  to  define  a  parts  condemnation  task  at  either 
base  or  depot  level  within  the  parts  network.  The 
part  completing  a  task  with  this  type  code  is 
consumed  and  removed  from  the  simulation.  No  other 
task  can  follow  a  Type  6  task. 

Type  7  -  Used  to  define  the  first  base  repair  task  in  the 
parts  network.  This  task  type  is  also  equivalent 
to  Type  2  and  is  needed  to  produce  post  processor 
data. 


NOTE:  Task  Types  4  and  7  cannot  be  used  in  series. 

b.  Definition  of  LCOM  Action  Taken  (AT)  codes  are  relatable  to 
maintenance  action  taken  codes  reported  on  AFTO  Form  349. 


LCOM 

AT  CODE  INCLUDES 

M  F,  G,  J,  K,  L,  V,  and  Z  maintenance  action  taken  codes  on  aircraft. 

R  R  and  P  action  taken  codes  (excluding  those  with  HOW  MAL  codes  799, 

800,  and  801). 

T  Y  action  taken  code  (excluding  799,  812,  and  948  HOW  MAL  codes). 

X  S  action  taken  codes  and  P  action  taken  codes  with  HOW  MAL  codes  799, 

800,  and  805. 

H  H  action  taken  codes  and  Y  action  taken  codes  with  HOW  MAL  codes, 

700,  812,  948. 


V 

W 

K 

N 


X  action  taken  codes 
A,  G,  J,  L,  V,  Z,  M, 
B  and  X  action  taken 
D,  1,  2,  3,  4,  5,  6, 


on  equipment. 

N,  C,  F,  action  taken  codes  off  equipment, 
codes  off  equipment. 

7,  8,  and  9  action  taken  codes. 


c.  For  new  weapon  systems,  the  contractor  supplied  Logistics  Support 
Analysis  Report  (LSAR)  should  be  used.  This  LSAR  provides  contractor  estimates 
to  the  shop  replaceable  unit  (SRU)  level.  It  is  updated  as  the  acquisition 
progresses . 


The  most  important  LCOM-related  data  obtained  from  the  LSAR  is  the 
manf acturer ' s  estimate  of  the  Mean  Time  Between  Maintenance  Actions  (MTBMA). 
This  parameter  combines  the  minor  maintenance,  'remove-and-replace",  and 
"can-not  duplicate"  actions.  The  actions  required  to  compute  the  MTBMA  are  the 
standard  reliability  failures  (Type  1,  2,  and  6).  [Refer  to  AFR  80-5  for  more 
information.]  This  value  is  used  in  the  determination  of  the  unscheduled 
maintenance  failure  clocks  for  "on -equipment"  or  "off-equipment"  actions  in  the 
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model . 


d.  Node  Names: 

(1)  Main  Networks  (flightline  networks)  should  be  prefixed  with 
MN  followed  by  0001  and  listed  sequentially.  For  example,  MNQ001,  MN0002, 

MN0003,  etc.  If  more  description  is  wanted  to  define  mission  type  or  action 
being  accomplished,  a  short  abbreviation  can  follow  the  MN  prefix.  For  example, 
the  functional  check  flight  networks  would  be  MNFCF1,  MNFCF2,  etc.,  and  the 
weather  cancel  networks  could  be  MNWX01,  MNWX02,  etc.  Scheduled  and  special 
inspection  networks  will  be  prefixed  with  SI.  Phase  networks  will  be  prefixed, 

PH  followed  by  the  phase  number,  if  used.  For  example,  nodes  for  phase  4  would 
be  PH4001,  PH4002,  PH4003,  etc.  Common  phase  networking  would  be  PH0001,  PH0002, 
PH0003,  etc. 

(2)  Unscheduled  maintenance  node  names  are  derived  directly  from 
the  WUC.  The  first  digit  of  the  WUC  is  converted  to  an  alpha  character.  For 
example,  the  11  WUC  area  would  be  represented  by  A,  23  by  B,  45  by  D,  72  by  6, 
etc.  The  second  and  third  digit  of  the  NUC  would  follow  the  alpha  character. 

The  fourth,  fifth,  and  the  sixth  digits  of  the  node  name  is  optional.  However, 
the  user  should  use  a  naming  technique  that  allows  the  flow  of  work  to  be 
followed  from  one  task  to  the  next.  For  example,  node  names  for  work  being 
performed  on  WUC  11120  could  be  coded  A11200  followed  by  A11201,  A11202,  A11203, 
etc.  The  Automatic  Network  Generator  (ANG)  follows  this  naming  convention. 

e.  LCOM  clock  names: 

(1)  Unscheduled  maintenance  clock  names  should  be  six  (6)  digits, 
with  an  "F"  in  the  first  position  and  WUC  In  the  following  five  (5)  positions. 

If  more  than  one  clock  exists  for  the  same  WUC,  the  last  position  should  be  used 
to  distinguish  them.  For  example,  F72A00  could  indicate  the  failure  clock  for 
postflight  maintenance  and  F72A0L  could  indicate  the  failure  clock  for  quick 
maintenance  at  launch. 

(2)  Other  failure  clocks  should  be  Identified  by  an  "F"  in  the 
first  position  and  a  descriptive  abbreviation,  as  appropriate.  (A  "Z"  is  used 
on  the  Extended  Form  11s  to  delink  the  clock  from  CALLS1  when  the  PHASE  programs 
are  run). 


(3)  Halt  clocks  should  be  identified  by  an  "H"  in  the  first 
position  and  WUC  or  description  abbreviation,  as  appropriate. 

f.  LCOM  resources  name 

(1)  Manpower  resources  are  identified  by  the  five  (5)  digit  Air 
Force  Specialty  Code  (AFSC)  (excluding  shred).  Where  the  same  AFSC  works  in 
different  post  manning  situations,  different  work  centers,  different  locations, 
or  has  shreds  that  need  to  be  separately  Identified,  the  fourth  (skill  level) 
position  of  the  AFSC  is  used  to  carry  distinguishing  alpha  codes.  The  last 
character  (sixth  position)  will  be  used  for  the  “Resource  by  location"  capability. 

Suggested  Codes  for  typical  breakout  are: 

462G0  ®  Gun  Services 
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462W0  =  Weapons  Release 

462L0  =  Weapons  Loading 

431R1  =  End  of  Runway 

431A1  «  Alert 

431  PI  =  Phase  Dock 

431  Cl  =  Aero  Repair 

431X1  =  Flightline  Service 

(2)  No  standard  is  established  for  AGE  resource  names  at  this  time. 

(3)  Parts  are  identified  by  WllC. 

g.  Naming  conventions  for  multiple  aircraft  and/or  multiple  base 
simulations: 


(1)  Task  names  may  utilize  an  alpha  equivalent  in  either  or  both 
of  the  first  two  work  unit  code  (WUC)  positions  to  distinguish  tasks  performed 
on  a  second  aircraft  type  or  at  different  locations. 

(2)  Node  names  may  use  any  combination  of  numerics  or  alpha 
equivalents  in  the  first  two  WUC  positions. 

(3)  Resource  names  and  clock  names  may  use  alpha  equivalents  in 
the  first  two  work  unit  code  positions. 

h.  General  considerations  in  developing  LCOM  networks: 

(1)  Network  with  the  least  number  of  clocks  and  tasks  necessary 
to  accomplish  the  objectives  of  the  study.  Separate  tasks  are  required,  as  a 
minimum,  wherever  there  is  a  difference  in  task  resource  requirements.  Avoid 
overly  complicated  networking  logic  unless  it  makes  a  measurable  difference  in 
output  statistics  or  simulation  efficiency. 

(2)  Use  separate  networks  for  tasks  with  different  distributions 
of  time  or  frequency  where  such  differences  could  impact  sortie  generation. 

For  example,  the  repair  of  failures  that  are  found  only  when  the  aircraft  is 
torn  down  for  phase  inspection  should  only  be  shown  in  phase  networks,  and  not 
lumped  together  with  flightline  dispatches.  Where  different  maintenance 
procedures  with  significantly  shorter  task  times  are  used  to  correct  failures 
discovered  at  launch,  they  should  be  shown  in  separate  networks  than  are  used 
for  postsortie  maintenance.  Where  procedures  and  times  are  similar,  tasks 
performed  at  different  points  in  time  may  process  through  the  same  networks. 

In  this  case,  the  relative  frequency  of  occurrence  at  each  point  is  controlled 
by  decrementing  values  established  on  the  basis  of  “when  discovered"  code  data, 
provided  that  no  single  decrement  value  exceeds  the  value  of  the  decremented 
clock. 


(3)  A  primary  advantage  of  LCOM  is  the  ability  to  relate 
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maintenance  demands  to  specific  mission  requirements  through  the  failure  clock 
and  decrementing  mechanism.  Failure  clocks  should  be  used  to  drive  maintenance 
frequency  wherever  maintenance  is  a  function  of  equipment  usage  (flying  hours 
or  sorties)  or  elapsed  operating  time  (as  in  a  phase  inspection).  The  clock 
values  and  decrements  should  be  in  terms  of  the  most  direct  measure  of  usage 
that  can  be  obtained  (sorties  by  mission  type,  operating  hours,  rounds  fired, 
etc.) . 


(4)  Tasks  which  cannot  be  done  concurrently  with  other  tasks  should 
be  networked  in  sequence  (or  in  sequential  call  sections).  Examples  are  engine 
run-up,  defuel ing,  and  jacking.  Where  there  is  a  high  probability  that  more 
tasks  will  be  processed  in  parallel  than  space  limitations  around  the  aircraft 
will  allow  (as  in  loading  and  servicing  on  turnaround),  tasks  may  be  grouped  into 
two  or  three  linear  strings  of  call  sections.  The  extent  of  parallel  versus 
sequential  networking  can  have  a  significant  affect  on  aircraft  turnaround  time 
and  on  the  timing  of  peak  manpower  demands.  In  some  instances,  it  is  appropriate 
to  allow  tasks  in  parallel,  but  force  them  into  an  optimal  sequential  order  by 
resource  constraints.  For  example,  a  large  number  of  preflights  may  be  scheduled 
at  one  time,  but  will  be  done  in  sequential  order  if  only  a  few  crew  chiefs  are 
provided. 


(5)  Care  must  be  taken  to  use  the  consume  and  generate  logic 
properly.  The  generate  task  (asterisked  task)  releases  the  primary  resource 
(e.g.,  aircraft)  and  causes  a  new  resource  to  be  generated  which  then  proceeds 
through  the  network.  Consumes  and  generates  are  a  powerful  logic  mechanism  to 
create  dependencies  between  otherwise  separate  missions  or  networks,  to 
temporarily  remove  a  failed  resource  from  the  simulation  so  it  cannot  be  used 
or  preempted,  and  to  keep  account  of  resources  transferred  from  one  location  to 
another.  However,  consumes  and  generates  for  each  resource  must  remain  in 
balance  for  a  stable  simulation  run. 

B.  MAIN  AIRCRAFT  SERVICING  NETWORKS 

(1)  Content  and  Data  Sources:  -  At  this  point  it  would  be  a  good  idea  for 
the  reader  to  go  back  and  briefly  review  Figure  3.  The  Form  20  described  in 
Section  III,  specifies  when  missions  are  to  be  flown  and  their  preparation 
leadtime.  (Refer  to  AFMSMET  Report  78-5.1)  This  controls  when  servicing  and 
maintenance  jobs  must  start.  The  task  sequences,  the  resources  needed,  and  the 
time  it  takes  to  do  the  work  are  put  into  the  model  in  network  format.  The  form 
that  ASD  uses  to  input  this  data  is  the  AF  Form  2719,  Extended  Form  11  (See 
Figure  32). 

The  main  aircraft  servicing  networks  cover  work  done  by  the  organizational 
maintenance  squadron  and  the  munitions  maintenance  squadron  load  teams  in 
launching  and  recovering  aircraft.  They  also  include  certain  scheduled 
inspections  and  service  work  by  other  specialists  that  is  regularly  done  in 
conjunction  with  preflight  or  post  flight  inspections. 

Maintenance  data  collection  (MDC)  data  on  similar  systems  is  not  much  help 
In  modeling  munitions,  loading,  or  crew  chief  work.  However,  HQ  TAC's  report 
"Modeling  Procedures  for  Munitions  Storage/Handling  and  Buildup",  dated  1  Nov 
81,  could  provide  some  help  in  the  munition's  area.  Work  unit  codes  for  this 
area  are  not  detailed  enough,  and  the  level  of  reporting  is  not  that  accurate. 
The  operations  concept  for  the  new  aircraft  is  a  better  starting  point.  The 
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Figure  32.  AF  Form  2719  -  Extended  Form  11 


requirements  office  at  the  operating  command  headquarters  can  assist  in 
translating  an  operations  concept  into  specific  assumptions  and  task  sequences. 
For  example,  do  aircraft  have  to  be  towed  into  shelters  when  they  land  or  do 
they  taxi  to  revetments?  If  towed,  will  three-man  or  five-man  tow  teams  be 
required?  If  they  taxi,  who  guides  them  in  and  parks  them?  Taxi  time  and 
maintenance  travel  time  could  depend  on  the  distance  revetments  are  dispersed. 
What  kind  of  fueling  facilities  will  be  available?  Will  aircraft  taxi  right  to 
fueling  pits,  or  wait  for  a  truck  to  come  around  during  postflight? 

Visit  an  organizational  maintenance  squadron  at  a  base  flying  aircraft  of 
the  same  type  and  similar  mission,  and  discuss  in  detail  what  they  do,  who  does 
it,  and  in  what  order.  Aircraft  servicing  tasks  and  sequences  tend  to  be 
generally  similar  in  the  same  command,  and  more  so  for  aircraft  flying  the  same 
type  of  missions.  The  preflight  and  postflight  technical  orders  (checklists) 
for  similar  aircraft  should  be  reviewed  for  similarities  and  differences  with 
the  new  aircraft.  The  time  estimates  obtained  from  experienced  line  and  crew 
chiefs  on  similar  aircraft  can  then  be  adjusted  for  these  differences,  to  get 
task  estimates  for  the  new  aircraft.  Published  munitions  loading  standards  can 
be  useful  data  sources  where  loads,  release  mechanisms,  and  loading  heights  are 
comparable.  Again  judgement  must  be  used  to  factor  for  identified  differences. 
Many  safety  standards  and  policies  will  apply  across  all  aircraft  in  a  command. 

A  detailed  review  of  the  04  series  of  special  inspection  work  unit  codes  listed 
in  the  06  technical  manuals  for  aircraft  of  the  same  type  can  suggest  many 
inspection  tasks  that  may  be  applicable.  Service  and  inspection  requirements 
identified  by  the  contractor  should  be  evaluated  and  included.  However, 
contractor  task  times  and  crew  sizes  usually  depict  touch  times  rather  than  the 
time  people  are  tied  up  on  the  job,  and  their  crew  sizes  may  not  reflect  actual 
practice.  Experienced  maintenance  technlcans  from  the  operating  command  who 
have  had  a  chance  to  observe  maintenance  on  prototypes  or  test  aircraft  are  a 
better  source  of  information  and  provide  more  realistic  estimates. 

The  access  necessary  in  order  to  do  each  task  should  be  analyzed  as  soon 
as  mockups,  prototypes,  or  test  aircraft  can  be  seen.  Access  is  peculiar  to 
the  new  aircraft  design  and  cannot  be  identified  from  data  on  other  systems. 

For  example,  the  A-10  manning  requirement  was  reduced  by  providing  an  easier 
way  to  get  an  engine  oil  sample  during  postflight.  This  change  was  made  at  an 
early  mockup  review  before  the  design  was  firm.  Main  network  tasks  should  be 
given  a  lot  of  attention  because  they  can  have  the  biggest  impact  on  manning. 
Cutting  one  man  off  a  maintenance  crew  or  saving  time  by  an  easier  access,  can 
have  a  big  payoff  in  the  manning  that  will  finally  be  required. 

(2)  Coding  the  Networks: 

(a)  General  -  A  Network  names  the  tasks  that  have  to  be 
accomplished,  and  shows  the  order  in  which  they  are  to  be  done.  It  also 
identifies  the  time  and  resources  needed  for  each  task.  Nodes  or  connection 
points  specify  the  task  processing  sequence  to  the  computer.  However,  every 
task  does  not  always  have  to  be  done  in  the  same  sequence.  Doing  a  task  can  be 
made  contingent  on  a  probability  or  on  the  occurrence  of  some  other  simulation 
event . 

Network  data  is  entered  on  an  Extended  Form  11  (AF  Form  2719).  The  use  c* 
the  Extended  Form  11  in  building  a  data  base  in  lieu  of  using  the  LCOM  forms  has 
the  following  advantages:  (1)  less  forms  to  prepare  and  have  keypunched;  (2) 
less  time  required  to  quality  control  keypunch  output;  (3)  the  basic  data  base 
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can  be  built  faster;  and  (4)  storage  of  the  data  is  more  compact.  It  is 
not  the  complete  solution.  Phase  output  requires  the  addition  of  LCOM  Forms 
17,  21,  22,  and  23  and  the  completion  of  the  Forms  14,  10,  12  (If  Form  12  is 
required)  before  the  initialization  can  be  run. 

The  Extended  Form  11  program  takes  user  prepared  data,  task  names,  task 
times,  resources,  and  reliability  data  imprinted  on  one  form  and  generates  the 
Forms  10s,  Form  11s,  Form  12,  Form  13s,  Form  14s,  Form  16s  and  Form  18s,  from 
the  PHASE  program. 

The  following  information  is  taken  from  "Extended  Form  11  Processor  User 
Reference  Manual",  dated  August  1979.  A  single  main  network  includes  all  the 
flightline  schedule  maintenance  tasks  performed  before  and  after  sorties.  This 
network  also  includes  CALLS 1  tasks  to  call  up  most  unscheduled  maintenance. 
Unscheduled  maintenance  is  modeled  in  networks  generally  corresponding  to 
systems  or  subsystems. 

Unscheduled  maintenance  networks  begin  with  an  "F"  task  that  defines  the 
failure  clock  (but  has  no  time  or  resources)  followed  by  tasks  defining 
subsequent  flightline  and  shop  corrective  actions.  The  variable  NCLOK  is  used 
for  PHASE  program  processing  and  then  discarded. 

Task  time  and  resources  must  be  defined  for  each  task  the  first  time  that 
the  task  appears  in  a  network.  The  PHASE  program  generates  a  Form  12  for  the 
task  the  first  time  it  is  encountered.  Any  subsequent  uses  of  the  same  task 
anywhere  in  the  model  are  entered  with  time  and  resources  blank. 

(b)  Extended  Form  11  Field  Description  -  There  are  three  (3) 
basic  formats  used  to  interpret  the  Extended  Form  11.  The  first  is  for  header 
cards,  the  second  is  for  failure  and  halt  clocks,  and  the  last  is  for  the  rest 
of  the  cask  networks. 

Figure  33  gives  field  description  for  each  format.  The  card  column  fields 
of  the  Extended  Form  11  are  self-explanatory,  but  the  user  has  to  have  some 
knowledge  of  how  the  program  works  in  building  the  other  forms,  i.e.,  when  an 
asterisk  is  placed  in  card  column  39,  what  resource  identification  is  going  to 
be  printed  on  the  Form  12?  The  networker  filling  out  the  form  should  know  when 
parts  are  being  consumed  and  generated  properly.  Therefore,  he  should  realize 
that  the  part  defined  on  the  header  card  is  going  to  be  shown  on  the  LCOM  Form 
12.  The  detailed  data  needed  to  accomplish  the  Extended  Form  11  is  dependent 
upon  the  program  processing  the  data;  therefore,  no  details  on  the  preparation 
of  the  form  are  included  here. 

Figure  34  is  an  example  of  a  network  coded  on  (Figure  34)  Extended  Form  II 
with  its  network  schematic  (Figure  35)  to  show  the  use  of  the  network  coding 
that  has  been  standardized. 

The  PHASE  program  will  make  the  following  shortcuts  or  assumptions  in  its 
processing: 


(a)  A  PDEPOT  task  will  be  added  to  the  end  of  all  shop  tasks  with 
LCOM  action  code  "N"  and  followed  by  a  blank  node. 

(b)  All  failure  clocks,  not  starting  with  a  "Z"  will  be  connected 
to  CALLS1 .  The  stringing  will  occur  in  groups  of  ten  starting  with  node  100 
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and  going  to  101,  102,  etc. 

.(c)  Decrementing  tasks  are  not  put  on  the  Form  14s.  They  must  be 
put  in  before  running  the  INPUT  module. 

(d)  Resource  substitution  by  location  and  resource  substitution  by 
itself,  cannot  be  handled.  For  resource  substitution  by  location,  the  "L" 
selection  mode  and  parameter  are  recognized,  but  the  user  must  mannually  insert 
the  appropriate  Form  13s. 

(e)  Alternate  resource  groups  using  Form  12As  must  be  manually 
inserted,  if  desired. 

(f)  A  resource  that  my  enter  a  network  must  be  specified  by  the 
user  on  the  Form  13. 

(g)  Only  nine  clock  decrements  can  be  specified. 

(h)  The  quantity  per  aircraft  (QPA)  is  permitted  on  the  Form  13s 
for  parts.  There  is  no  method  for  the  user  to  specify  this  number  on  the 
Extended  Form  l'ls. 

(i)  If  multiple  header  cards  are  used,  only  the  last  comment 
appearing  in  the  string  of  Extended  Form  11s  (per  NCLOK)  will  be  placed  as 
comments  on  the  Form  11s  generated  by  PHASE. 

(3)  Coding  Network  Call  Sections: 

(a)  General  -  A  call  task  is  a  dummy  representing  all  the  tasks  in 
a  section  of  network.  All  applicable  tasks  within  the  section  must  be  done 
before  the  call  task  can  be  completed  or  any  following  task  started.  Tasks 
which  can  be  done  in  parallel,  but  where  all  constrain  some  subsequent  task, 
are  coded  in  call  sections.  In  ASD  LCOM,  no  parallel  tasks  can  precede  a 
sortie,  unless  they  are  in  a  call  section.  Call  sections  are  also  useful  where 
the  same  group  of  tasks  is  repeated  in  several  networks.  The  call  section 
tasks  are  det’vd  in  the  first  place  the  call  appears,  and  then  just  the  call 
task  is  used  i.  represent  the  section  later. 

The  call  task  is  represented  by  selection  mode  of  "C".  It  is  used  in  the 
network  where  the  request  originates. 

Any  number  of  tasks  can  be  defined  in  a  call  section,  from  one  by  itself 
to  hundreds  in  many  parallel  strings.  A  call  section  can  request  another  call 
section,  just  as  in  computer  programs,  subroutines,  external  to  the  main 
program,  can  be  accessed.  Note  that  a  specific  call  task  name  must  only  be 
defined  once  in  the  entire  model,  at  the  first  place  it  appears.  After  that, 
only  the  call  task  name  is  used  to  represent  all  the  tasks  in  that  call  section. 

(b)  Using  Call  Sections  for  Unscheduled  Maintenance  -  The 
relationship  between  the  main  networks  and  unscheduled  maintenance  networks  is 
shown  in  Figure  3.  Aircraft  break  as  a  result  of  flying.  The  failure  clocks, 
and  the  unscheduled  maintenance  work  to  fix  broken  aircraft,  are  defined  in 
call  sections.  Corrective  maintenance  tasks  are  only  called  where  the  failure 
clocks  indicate  something  is  broken.  If  nothing  is  broken,  or  when  repair  has 
been  completed,  the  program  will  continue  to  process  the  next  main  network  task. 
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Record  Type  1 
COLUMN 
13  -  17 
25 

24  -  38 
42  -  80 


-  Header  Card  Description. 

MODE  DESCRIPTION 

A  Line  replaceable  Unit  (LRU),  optional. 

A  Required  character  H  to  indicate  header  card  format. 

A  Current  network  clock  name,  required. 

A  Remarks  to  be  printed  on  LCOM  Form  11  cards. 


NOTE:  Header  cards  may  be  used  throughout  the  clock  network  as  comment  cards. 
For  those  users  who  also  wish  to  use  the  Expected  Value  Model  (EVM), 
check  the  ZVM  User  Reference  Manual  for  additional  information  required 
on  the  header  card. 


Record  Type  2 

—  Failure 

on  Halt  Clock. 

COLUMN 

MODE 

DESCRIPTION 

5  -  10 

A 

Prior  node. 

12 

A 

Action  taken  code  Z  is  used  if  the  clock  is  not  to  be 
chained  to  CALLS1 . 

13 

-  17 

A 

Work  Unit  code. 

19 

-  24 

A 

Next  node. 

26 

A 

Selection  mode  (F  or  H). 

27 

-  32 

R 

Mean  sorties  between  R,  M,  or  H  actions  (MSBF) . 

34 

-  38 

A 

Network  clock  name  (NCLOK). 

39 

A 

Release  field  —  must  be  blank. 

40 

-  41 

A 

Task  type  and  priority. 

48 

-  50 

I 

Percent  variance  to  be  used  on  the  MSBF  field  to 
compute  the  variance  for  LCOM  Form  13. 

51 

A 

Distribution  type  must  be  non-blank  if  the  percent 
variance  field  is  non-blank.  Default  for  halt  is 

"C"  and  for  failure  clock  is  "X". 

Figure  33.  Extended  Forms  11  Description. 
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Record  Tvoa  2 

—  Failure  or  Halt  Clock.  (Continued) 

COLUMN 

MODE 

DESCRIPTION 

52 

A 

Time  unit  for  MSBF  field.  If  blank,  no  time  unit 
placed  on  LCOM  Form  13. 

is 

54  -  58 

R 

Decrement  field  —  this  first  field  must  have  a 
number  for  "F"  selection  mode.  A  halt  clock  defaults 
to  1 .0. 

61  -  65 

R 

Decrement  field  for  LCOM  Form  14. 

68  -  72 

R 

Decrement  field  for  LCOM  Form  14. 

75  79 

R 

Decrement  field  for  LCOM  Form  14. 

Record  Type  3 

—  Other  Network  Cards. 

COLUMN 

MODE 

DESCRIPTION 

5  -  10 

A 

Prior  node. 

12 

A 

Action  taken  code. 

13  -  17 

A 

Work  Unit  code. 

19  -  24 

A 

Next  node. 

26 

A 

Selection  mode. 

27  -  32 

R 

Probability. 

34  -  38 

A 

Network  clock  name. 

39 

A 

Release,  may  be  blank,  *,  or  #. 

40  -  41 

A 

Task  type  and  priority. 

43  -  47 

A 

Average  task  time  in  tenths  of  hours  unless  HH+MM 
*1  format  is  used.  (See  column  52). 

or 

48  -  50 

I 

Percent  variance. 

51 

A 

Distribution  type. 

Figure  33.  Extended  Forms  11  Description  (cont'd) 
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Record  Type  3 
COLUMN 

52 

53 

54  -  58 
60 

61  -  65 

67 

68  -  72 

74 

75  -  79 
80 

NOTE:  Columns 


-  Other  Network  Cards.  (Continued) 

MODE  DESCRIPTION 

A  Time  unit  for  time  field,  columns  43-47.  If  this  is 

blank,  the  unit  is  set  to  tenths  of  hours  for  LCOM 
Form  12  unless  the  HH+MM  or  *1  format  is  used.  This 
value  may  be  D,  H,  or  M. 

A  Crew  size  for  the  following  resource. 

A  AFSC  or  AGE  requirement. 

A  Crew  size  for  the  following  resource. 

A  AFSC  or  AGE  requirement. 

A  Crew  size  for  the  following  resource. 

A  AFSC  or  AGE  requirement. 

A  Crew  size  for  the  following  resource. 

A  AFSC  or  AGE  requirement. 

A  Resource  list  to  continue  flag. 

12-17  serve  as  the  task  name. 


Figure  33.  Extended  Forms  11  Description  (concluded) 
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Figure  35.  Network  that  Is  Coded  in  Figure  34. 


All  unscheduled  maintenance  that  could  be  done  concurrently  is  usually 
defined  in  a  single  large  call  section  named  CALLS1 .  The  data  base  processing 
programs  automatically  provide  the  necessary  starting  tasks  to  define  CALLS1 . 
Unscheduled  maintenance  that  would  conflict  with  other  work  and  must  be  done 
by  itself  is  shown  in  separate  sequential  call  sections.  Examples,  of  such 
work  are  repairs  requiring  aircraft  jacking,  or  towing  to  a  test  cell  for 
engine  runup. 

When  failures  are  discovered  on  a  loaded  aircraft  just  prior  to  a  sortie, 
the  munitions  must  be  dearmed  (cartridge  ejectors  removed)  before  any 
maintenance  work  is  done.  In  some  cases,  such  as  jacking  or  engine  runup,  the 
ordinance  may  have  to  be  off-loaded.  This  can  be  modeled  using  F-task 
stringing  as  described  in  Section  V,  paragraph  C  4  (a). 

Decrement  tasks  are  inserted  in  the  main  networks  to  show  where  failure 
clocks  are  to  be  decreased.  The  appropriate  decrements  advancing  the  clocks 
must  precede  the  unscheduled  maintenance  call  sections  that  check  to  see  if 
there  is  a  resulting  failure.  Decrements  can  be  defined  to  advance  clocks  by  a 
whole  sortie  or  fractions  of  a  sortie,  and  can  be  setup  to  advance  some  clocks 
and  not  others.  Each  uniquely  named  decrement  task  advances  a  particular  set 
of  clocks  by  a  specific  amount. 

Usually,  decrement  tasks  are  coded  on  the  Extended  Forms  11  with  a  task 
name  DCRMT  and  a  unique  number,  with  the  "D"  starting  in  column  12.  The 
selection  mode  in  column  26  is  "D",  and  probabilities  and  resources  are  left 
blank.  However,  any  task  may  be  used  to  decrement  a  clock.  The  Form  14  is 
used  to  list  the  failure  clocks,  the  decrementing  task,  and  their  appropriate 
decrement. 

C.  PREFLIGHT  TO  POSTFLIGHT  NETWORK  EXAMPLE 

The  remainder  of  this  section  illustrates  main  network  coding  and 
construction  using  a  number  of  detailed  examples  of  situations  that  were 
encountered  in  developing  LOOM  models  for  tactical  aircraft.  Figure  36  is  the 
preflight  and  postflight  network  for  an  A-7D,  and  Figure  37  shows  how  it  is 
coded  on  the  Extended  Form  11. 

It  takes  one  crew  chief  an  average  of  3.6  hours  to  preflight  (HPRFLT)  an 
A-7.  They  do  not  double  up  to  shorten  the  time,  even  in  combat,  although  this 
could  be  done.  LOX  (HLDXSV),  nitrogen  and  air  (HNARSV)  are  serviced  during 
preflight.  These  are  shown  as  separate  tasks  because  different  people  do  the 
work.  The  crew  chief  removes  the  LOX  bottle  and  places  it  at  the  nose  wheel  if 
it  needs  refilling.  It  is  needed  on  about  40%  of  the  preflights  so  this  task 
is  coded  with  an  "A"  selection  mode  with  a  probability  value  of  .40.  On  the 
other  60%  H  will  be  skipped.  To  service  LOX,  one  431X1  goes  around  and  picks 
up  the  bottles.  Another  431X1  refills  two  (2)  at  a  time,  taking  an  average  of 
15  minutes  per  bottle.  This  task  is  shown  as  requiring  two  (2)  431 XI s  for  two 
hours  using  one  (1)  LOX  servicing  cart  (LCART).  Two  (2)  other  431 XI s  take  a 
service  cart  (MCART)  to  each  aircraft  during  preflight  to  replace  nitrogen 
bottles  as  required,  and  to  service  tire  air.  This  task  (HNARSV)  requires  two 
(2)  431X1  APGs  (Airplane  General)  for  .2  hours  per  aircraft.  Since  nitrogen 
and  air  are  checked  every  time,  selection  mode  "D"  is  used.  Since  the  crew 
chief  preflight  (HPRFLT),  LOX  service  (HLOXSV),  and  nitrogen/air  service 
(HNARSV)  are  parallel  tasks  constraining  start  of  the  next  main  network  task, 
loading  (BL0DR4),  they  must  be  coded  in  a  call  section. 
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Figure  36.  Example  of  Preflight  to  Postflight  Main  Network. 
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figure  37.  Example  of  Preflight  to  Postflight  Main  Network  Coding  orr  Extended  Form  11  (Concluded) 


The  example  mission  involves  a  bomb  load  (BLQDR4)  only  (no  gun  or  camera), 
and  takes  a  4-MAN  load  crew  an  hour  using  standard  loading  equipment.  This  time 
was  computed  by  summing  TACM  50-7  Standards  for  the  particular  ordinance  load 
and  adding  fifteen  (15)  minutes  for  travel.  The  launch  (engine  start)  task 
(HEN6ST)  covers  all  elapsed  time  from  the  point  the  pilot  joins  the  crew  chief 
at  the  aircraft  for  walk  around  until  the  start  of  the  taxi.  It  takes  an 
average  of  .8  hours  and  includes  time  that  the  crew  chief  stands  by  while  the 
pilot  performs  his  checks  and  runs  up  the  engine  with  the  plane  in  chocks. 

CONUS  policies  on  download  (BDWNLD)  vary  by  base.  Combat  aircraft  are 
never  downloaded  if  at  all  possible.  The  only  situation  in  which  an  aircraft 
must  be  downloaded  are:  An  engine  problem  requiring  runup  in  the  test  cell;  a 
jacking  problem  involving  more  than  one  wheel;  failure  of  weapons  control/ 
release  systems;  work  on  the  fuel  cells,  or  if  the  aircraft  must  go  into  a 
hangar  (PHASE).  Of  these,  only  engine  problems  and  jacking  have  a  fair 
likelihood  of  occuring  as  a  ground  abort  (between  engine  start  and  takeoff). 

When  a  ground  abort  for  engine  or  landing  gear  occurs,  the  download  and  upload 
are  shown  together  in  one  task  for  networking  convenience,  even  though  the 
upload  portion  would  occur  much  later.  (This  simplification  should  not  make  any 
significant  difference  in  the  simulation  results).  In  most  cases,  ground  abort 
will  only  require  a  dearm  task  (removing  cartridge  ejectors),  and  then  a  rearm 
and  repeat  of  stray  voltage  checks  when  the  maintenance  is  completed.  Dearm  and 
rearm  are  also  networked  in  a  single  task  (BDEARM).  The  call  sections  are 
checked  in  sequence  (using  "F"  task  stringing)  and  if  there  is  no  failure,  the 
aircraft  proceeds  to  taxi  (JTAXIl).  This  taxi  task  consumes  time,  but  no 
resources. 

Three  (3)  431 R1  (four  required  in  combat)  are  stationed  at  the  end-of -runway 
(EOR)  for  final  launch  check  (HRUNW1).  One  of  these  is  a  team  chief  who  talks  to 
the  pilot  via  intercom.  Two  (2)  munitions  men  (462R0)  are  also  part  of  the 
launch  EOR  team  to  pull  the  pins  on  ordinance.  All  EOR  crews  are  stationed  there 
for  a  full  eight  (8)  hour  shift.  EOR  check  is  shown  in  the  networks  as  a  .1  hour 
task  for  two  (2)  431Xls  and  two  (2)  462R0s  after  a  .2  hour  taxi.  A  dedicated 
crew  is  not  available  for  any  other  work  and  must  be  treated  as  a  separate  AFSC 
in  LCOM.  Runway  checks  are  uniquely  identified  by  an  "R"  in  the  fourth  digit  of 
their  AFSC.  t 

The  sortie  task  (SORTIE)  removes  the  aircraft  from  the  simulation  for  a 
random  time  according  to  the  sortie  length  distribution  specified  on  the  Form  20. 
The  Extended  Form  11  does  not  require  any  time  or  resource  entry  for  a  sortie 
task.  Sortie  tasks  are  coded  with  an  "S"  Selection  Mode  and  there  is  only  one 
sortie  allowed  per  main  network. 

Two  (2)  462R0  munitions  men  are  stationed  at  the  other  end  of  the  runway  to 
check  returning  aircraft  for  hung  ordinance  and  to  "safety"  ordinance  not 
dropped  (task  HRUNW2) .  One  (1)  431R1  APG  is  also  part  of  the  recovery  EOR  team 
to  park  the  aircraft  for  the  ordinance  EOR  check.  While  the  aircraft  is  taxiing 
in,  the  crew  chief  and  an  AGE  handler  are  getting  ready  for  recovery  in  the 
parking  area.  Their  work  is  shown  on  the  taxi  task  (JTAXI2) .  The  crew  chief 
then  parks  the  aircraft  in  the  .1  hour  recovery  task  (HRECOV). 

Aircraft  are  fueled  in  the  parking  area  or  revetment  when  the  fuel  truck 
arrives.  The  postflight  is  interrupted  to  allow  two  431X1 s  and  one  POL  driver 
to  refuel  the  aircraft  (GAS100).  For  the  purpose  of  modeling,  fueling  is  shown 
prior  to  postflight.  This  slight  disparity  with  the  actual  time  sequence  makes 
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no  difference  in  the  LCOM  output  since  fuel  trucks  are  not  constrained. 

Fueling  an  empty  A-7  requires  .3  hours,  and  less  time  If  the  plane  still  has 
fuel  aboard.  In  this  example,  the  plane  returns  from  air  refueling  with 
practically  full  tanks,  so  the  task  time  is  .2  hours  by  two  (2)  431Xs.  The 
Petroleum,  Oil  and  Lube  (POL)  driver  is  not  part  of  the  maintenance  unit  for 
which  manning  Is  being  determined,  so  he  was  not  included  in  the  model. 

The  aircraft  is  not  to  be  turned  for  another  mission  and  goes  into  a 
3.7  hour  end-of-day  full  postflight  by  the  crew  chief.  End-of-day  postflight 
on  the  A-7  Includes  an  oil  chip  check  (HCHPCK)  requiring  one  (1)  432X0  for 
three  (3)  hours.  Unscheduled  maintenance  Is  done  In  parallel  with  postflight 
(HFPST1)  except  for  engine  or  autopilot  work  requiring  engine  runup  and/or 
functional  checkfllght,  and  work  requiring  jacking  the  aircraft.  These  call 
sections  are  networked  In  sequence  after  CALLS1 ,  unscheduled  maintenance  Is 
completed.  After  all  required  network  tasks  are  finished,  the  aircraft  Is 
released  for  another  mission  assignment  (controlled  by  the  Form  20s). 

0.  "QUICK  TURN”  NETWORKING  EXAMPLE 

If  an  aircraft  is  to  fly  again  the  same  day,  It  is  given  a  thruflight 
rather  than  a  full  end-of-day  postflight.  This  Is  normally  a  requirement  when 
modeling  a  surge  scenario  although  It  could  be  used  In  peacetime  as  well. 

One  way  to  adequately  model  this  situation  is  to  place  all  presortie  tasks 
except  for  the  engine  start,  tax1,*and  end-of-runway  check,  In  configuration 
networks.  This  will  allow  use  of  a  "cocked"  aircraft  resource,  without 
repeating  work  already  accomplished.. 

Figure  38  Is  an  example  of  this  modeling  technique.  Each  mission  will 
require  a  certain  configuration  class.  (Refer  to  the  section  on  Configuration 
Management  In  Chapter- 1 II,  paragraph  B).  If  the  aircraft  Is  not  In  the 
required  configuration.  It  will  be  reconfigured  by  entering  Node  CN0001 .  A 
comprehensive  aircraft  check  (PRPO)  Is  required  once  every  21-hours;  the  "J" 
Selection  Mode  Is  used  to  represent  this.  The  next  tasks  In  line  are 
servicing  (SERVIC)  and  loading  munitions  (LOAD).  These  are  performed  each  time 
this  network  is  used. 

The  first  node  in  the  main  network  Is  the  task  for  starting  the  engine 
(STENG).  Modeling  the  main  in  this  manner  allows  for  any  "cocked"  aircraft  to 
do  the  minimum  tasks  required  to  take-off.  A  Taxi  (TAXI1)  and  an  end-of-runway 
(EORCK)  precede  the  actual  sortie  (SORTIE). 

After  the  aircraft  has  flown,  the  unscheduled  maintenance  failure  clocks 
are  decremented  (DCRMT1 ) .  It  Is  assumed  in  this  model  that  unscheduled 
maintenance  Is  deferred  until  post  sortie.  This  assumption  would  be  derived 
from  the  operational  scenario. 

After  the  aircraft  has  landed,  It  can  do  one  of  two  things.  It  can  either 
Immediately  taxi  (TAXI2),  which  It  will  do  96X  percent  of  the  time;  or  download 
any  hung  munitions  and  taxi  (combined  In  the  task,  DWNLD),  the  remainder  of  the 
time.  An  abbreviated  thruflight  (POSFLT)  Is  accomplished,  the  aircraft  Is 
parked  (PARK)  and  then  refueled  (REFUEL).  The  maintenance  call  (CALLS1)  Is 
performed  last.  Please  remember  that  this  Is  an  example  only.  To  model 
real-life  situation,  other  factors  would  need  to  be  considered. 
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SECTION  VII 


CORRECTIVE  MAINTENANCE  TECHNIQUES 

A.  CONTENT  AND  DATA  SOURCES 

The  networks  covering  unscheduled  corrective  maintenance  tasks  are 
located  by  subsystem  and  broken  up  into  call  sections.  Usually,  they  are 
called  from  the  main  network  using  the  CALLS1  task  (explained  previously). 

Each  network  must  start  with  a  failure  clock  and  parameter  value  of  mean 
sorties  between  failure  actions  (MSBMA) .  This  controls  the  frequency  with 
which  the  network  tasks  will  be  processed.  It  must  cover  all  the  times  a 
specialist  is  called  to  the  aircraft  in  the  field  to  fix  an  apparent  problem, 
including  cases  where  only  some  minor  adjustment  is  required  or  the  system 
checks  out  OK.  This  definition  of  maintenance  frequency  differs  substantially 
from  reliability  measures  of  failure  that  consider  only  confirmed  breakage 
under  controlled  conditions. 

The  networks  also  contain  task  times  for  work  on  aircraft  and  in  field 
shops.  Depot  repair  tasks  are  not  handled  by  LCOM.  They  are  incorporated  in 
one  task,  PDEPOT,  which  takes  care  of  the  time  that  the  part  is  out  of  the 
simulation. 

The  corrective  maintenance  networks  represent  the  time  a  technician  is 
tied  up  on  the  job  and  not  available  for  other  work.  They  must  consider  time 
to  get  to  a  job,  time  to  fault  isolate  and  check  out  the  system,  time  to 
clean  up,  time  to  get  parts,  and  standing  time  on  multiple  crew  tasks.  They 
are  substantially  different  from  the  touch  times  developed  in  maintainability 
studies  prepared  by  the  contractor  (LSAR).  For  example,  a  cockpit  mounted 
radio  that  can  be  changed  in  a  few  minutes  by  removing  six  (6)  screws  might 
occupy  a  man  for  half  an  hour  when  total  job  time  is  considered. 

The  maintenance  crew  size  shown  for  network  tasks  represents  the  number 
of  people  typically  dispatched  to  the  job.  Crew  size  depends  on  safety 
factors,  maintenance  practice  in  the  operating  command  to  account  for  level 
of  skill,  the  need  for  technical  data  while  working,  policy  on  checking  work, 
accessibility  of  the  item,  and  on-the-job  training.  More  people  will 
generally  be  dispatched  than  are  indicated  by  a  strictly  touch-time  task 
analysis. 

Maintenance  frequency  task  times,  and  crew  sizes  for  new  weapon  systems, 
are  developed  by  Air  Force  past  experience  on  similar  equipment,  when 
possible.  The  Air  Force  Maintenance  Data  Collection  (MDC)  system  is  the  basic 
information  source  on  what  it  takes  to  maintain  current  equipment.  Air  Force 
engineers  and  experienced  technicians  must  then  evaluate  differences  and  apply 
judgement  factors  to  the  MDC  data  in  order  to  estimate  task  requirements  for 
the  new  design.  The  development  contractor  is  the  primary  source  of  design 
identification  and  engineering  information. 

B.  PROCEDURE 

The  first  step  is  to  define  the  proposed  design  of  the  new  aircraft. 
Definition  must  be  at  least  to  subsystem  level  and  preferably  to  line 
replaceable  unit  (LRU)  level.  The  contractor's  development  proposal,  submitted 
at  the  end  of  the  validation  phase,  will  usually  encompass  this  level  of  design 
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definition.  Much  useful  information  can  be  obtained  through  visits  to  the 
contractor's  facility  and  thorough  inspection  of  any  mockups,  prototypes,  or 
test  aircraft  under  construction.  If  there  is  a  flying  prototype,  experienced 
Air  Force  technicians  should  be  assigned  to  observe  and  evaluate  maintenance 
procedures  and  requirements. 

Riven  suitable  design  definition,  the  next  step  is  to  identify  comparable 
systems  and  subsystems  on  existing  aircraft.  Comparability  is  assessed  in 
terms  of  fu-  tion,  design  concept,  complexity,  operating  environment  and 
ma’  .tainabi . ,ty  features.  The  Air  Force  engineers  assigned  to  the  Systems 
Program  Office  (SPO)  and  their  "Home  Office"  supporting  cadre  should  conduct 
this  analysis,  and  it  should  be  coordinated  by  the  program  reliability/ 
maintainability  officer.  It  is  essential  that  the  analysis  and  rationale  be 
completely  documented  and  then  kept  current  in  each  participating  program  office 
engineering  group.  A  good  working  relationship  between  these  people  and  the 
LCOM  modelers  should  be  cultivated. 

The  comparability  analysis  should  be  structured  according  to  the 
contractor's  preliminary  work  unit  code  manual  at  the  subsequent  level.  The 
special  criteria  for  identifying  comparabilit.  must  be  defined  for  each 
subsystem  at  the  outset.  Experienced  maintenance  personnel  in  the  program 
office  and/or  operating  command  should  be  brought  in  to  familiarize  each  group 
of  engineers  with  maintenance  problems  typically  associated  with  their 
equipment,  and  jointly  establish  appropriate  criteria.  'letting  both  maintenance 
and  engineering  input  is  critical.  For  example,  in  one  comparability  study, 
airframe  engineers  initially  based  their  criteria  on  the  similarity  of  the  heavy 
loadbearing  structures  to  resist  stress  and  fatigue  cracking.  The  maintenance 
people  pointed  out  the  most  day-to-day  airframe  repair  work  involves  fitting 
skin  panels,  fitting  „ccess  doors,  and  replacing  fastners;  not  fixing  broken 
wing  struts.  The  kind  of  fastners,  curvature,  and  stress  on  surfaces,  and 
simple  size  of  the  aircraft,  ay  have  more  bearing  than  structural  design  on 
the  comparability  of  flightline  and  field  shop  maintenance.  However,  vibration 
absorbing  properties  of  the  structure  relate  to  the  cause  of  skin  maintenance 
and  cannot  be  ignored  either. 

Once  the  criteria  are  established,  the  engineers  compare  the  designs  of 
similar  aircraft;  drawing  on  the  experience  of  associates  who  have  worked  on 
various  programs,  contractor  data,  and  Air  Force  technical  orders,  as  necessary. 
The  results  are  then  written  up  by  subsystem  (3  digit)  work  unit  code,  to 
include:  identification  of  comparable  aircraft  and  subsystem  work  unit  code(s); 
any  additional  LRUs  in  the  new  subsystem  or  LRUs  by  work  unit  code  in  the 
comparable  system  that  are  not  applicable;  any  factors  that  should  be  applied  to 
the  comparable  suusystem  failure  rates  or  task  times  in  estimating  for  the  new 
subsystem;  and  a  narrative  analysis  specifying  the  criteria  used  and  supporting 
rational  for  choosing  the  comparable  subsystem  and  factors.  Any  scheduled 
maintenance  considerations  should  be  mentioned.  In  some  cases,  an  item  is  so 
new  or  changed  that  there  is  nothing  reasonably  comparable.  Iri  that  case, 
the  best  source  of  data  (contractor,  etc.)  should  be  identified,  and 
appropriate  factors  and  degree  of  confidence  discussed.  Study  results  should 
be  reviewed  in  conjunction  with  experienced  maintenance  personnel  to  be  sure 
that  no  maintenance  considerations  were  missed.  The  comparability  study 
requires  a  considerable  effort  on  the  part  of  program  office  engineers,  but  has 
a  payoff  in  their  better  understanding  and  heightened  awareness  of  maintenance 
considerations,  when  they  review  contractor  proposed  designs  and  design  change 
proposals. 
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The  next  step  is  to  obtain  MDC  data  tapes  on  aircraft  with  comparable 
subsystems,  and  process  this  information  through  a  series  of  specially  designed 
computer  programs,  the  Common  Data  Extraction  Programs  (CDEP).  These  programs 
and  processing  instructions  are  in  AFMSMMET  Report  78-4.  The  program  outputs 
are  in  a  convenient  format  for  use  in  developing  a  simulation  data  base. 
However,  some  base  visits  will  be  essential  to  verify  and  correctly  interpret 
certain  aspects  of  MDC  coding  for  the  comparable  subsystems,  and  help  identify 
certain  requirements  and  procedures  for  using  powered  AGE. 

The  verified  MDC  data  on  the  comparable  systems,  factored  for  identified 
design  differences,  is  used  to  build  an  LCOM  maintenance  data  base  for  the  new 
aircraft.  When  this  data  base  is  completed,  the  networks,  times,  and 
particularly  the  crew  sizes  and  AFSCs,  should  be  reviewed  with  experienced  Air 
Force  maintenance  personnel.  (Operational  command  technicians  on  prototype,  or 
test,  aircraft  make  ideal  reviewers.)  This  review  is  an  interative  process. 

The  basic  procedure  of  design  identification,  comparability  identification 
model  construction  with  MDC  data,  and  maintenance  review  is  repeated  on  design 
changes  to  keep  the  G<aa  base  current  throughout  the  development  and  production 
phases.  Test  and  operational  evaluation  data  is  considered  as  it  becomes 
available.  The  operating  command  has  a  vested  interest  in  the  accuracy  of  the 
model  as  it  will  be  eventually  transferred  to  them. 

( 1 )  Network  Structure 

The  basic  task  sequencing  for  a  corrective  maintenance  network  is  shown  in 
Figure  39.  It  must  begin  with  an  “F"  task  that  identifies  the  failure  clock. 
This  serves  as  a  gate  controlling  how  often  the  subsequent  network  tasks  are 
done.  The  gate  is  only  opened  and  tasks  processed  when  the  clock  on  the  "F" 
task  indicates  that  an  apparent  failure  has  occurred.  The  "F"  task  is  followed 
by  the  on-aircraft  maintenance  tasks  needed  to  describe  the  corrective  work,  on 
Figure  39: 


A  task  -  to  get  and  set  up  powered  AGE. 

X  task  -  to  gain  access  to  the  subsystem  or  LRU,  particularly 
when  done  by  a  different  AFSC  than  does  the  corrective 
action . 

T  task  -  to  troubleshoot  the  system. 

R  task  -  to  remove  and  replace  an  LRU. 

M  task  -  for  any  on-aircraft  fix  not  involving  LRU  removal. 

V  task  -  to  perform  an  inspection  or  functional  check  to  verify 
that  the  subsystem  has  been  fixed. 

These  tasks  are  coded  with  D,  E,  or  A  Selection  Modes  to  describe  the 
appropriate  sequence  of  work  at  subsystem  level.  The  "R"  task  is  an  average 
for  all  LRUs  in  the  subsystem  that  are  done  by  the  same  AFSC  and  crew  size.  If 
some  items  are  removed  by  a  different  AFSC,  these  must  be  grouped  into  a 
parallel  "R"  task  representing  the  set  of  LRUs  removed  by  that  AFSC  and  crew 
size.  "E"  Selection  Mode  probabilities  determine  which  corrective  task  is 
processed. 
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Figure  39.  Schematic  of  Maintenance  Network  Basic  Logic. 


"R"  tasks  are  normally  followed  by  a  shop  entry  task.  These  are  dummy 
tasks  because  "E"  and  "6"  selection  logic  cannot  be  run  out  of  the  same  network 
node.  It  is  followed  by  parallel  "L"  tasks  representing  failed  LRUs.  Six  (6) 
selection  mode  probabilities  determine  which  LRUs  within  the  subsystem  were 
removed.  The  following  tasks  are  used  to  represent  the  possible  shop  actions 
on  a  removed  LRU,  in  Figure  39: 

W  task  -  to  bench  check  and  repair  the  LRU. 

K  task  -  to  bench  check  the  LRU  and  find  it  serviceable. 

N  task  -  to  bench  check  the  LRU,  find  it  NRTS,  prepare  it  for 

shipment,  and  order  a  new  one  from  Depot. 

An  asterisk  can  be  placed  in  column  39  of  the  Extended  Form  11  on  a 
generate  task  to  indicate  that  a  shop  task  will  not  hold  up  the  aircraft  if  a 
spare  LRU  is  available.  A  "Q"  task  must  be  included  with  selection  mode  "D" 
and  no  asterisk  in  order  to  draw  a  spare  LRU  from  supply.  (An  "I"  mode  can  be 
used,  instead  of  the  "D",  if  cannibaliEation  is  desired.)  The  "N",  "W’\  and  "K" 
tasks  must  be  coded  with  selection  mode  "E"  to  assure  only  one  is  processed  to 
match  each  supply  demand.  The  asterisk  on  the  generate  task  tells  the  computer 
than  an  LRU  is  now  being  processed  instead  of  an  aircraft,  and  should  be 
returned  to  supply  when  the  task  or  task  sequence  is  complete.  It  effectively 
separates  the  shop  network  from  the  aircraft  network  unless  there  was  no  spare 
to  draw  from  supply. 

(2)  Coding  Conventions 

Node  numbers  for  on-aircraft  maintenance  tasks  are  five  (5)  digits,  right 
justified.  The  first  three  (3)  digits  correspond  to  the  first  three  (3)  digits 
of  the  subsystem  work  unit  code,  except  that  the  first  digit  is  entered  as  the 
corresponding  alphabetic  character.  The  last  two  (2)  digits  indicate  the  task 
sequencing.  For  example,  for  the  14A00  subsystem,  node  numbers  would  be  A4A00, 
A4A01,  A4A02,  etc.  For  the  42C00  subsystem  they  would  start  with  D2C00,  D2C01, 
D2C02,  etc. 

The  node  following  the  shop  dummy  task  and  preceding  the  "L"  task  is  six 
(6)  digits,  with  an  "S"  in  the  first  position,  followed  by  the  subsystem  work 
unit  code.  Subsequent  nodes  for  shop  tasks  are  also  six  digits,  with  "I"  in  the 
first  position,  the  first  four  (4)  digits  of  the  LRU  work  unit  code,  and  the 
last  position  used  for  task  sequencing  as  described  above.  For  example,  the 
prior  node  to  the  "L"  task  in  the  14A00  network  would  be  coded  SA4A00,  and  the 
next  node  might  be  IA4AA0.  These  node  numbering  conventions  may  seem  a  bit 
confusing  at  first,  but  they  a»c  'yrlckiy  mastered,  and  if  followed  help  prevent 
serious  node  duplication  errors  when  networks  are  modified  and  updated  later. 

In  order  to  accurately  use  the  Parts  Post  Processor,  task  Types  "4",  "6", 
and  "7"  should  be  used.  While  use  of  these  three  (3)  task  types  is  required  to 
use  this  post  processor  it  is  not  necessary  to  change  old  data  bases  if  it  is 
not  going  to  be  used.  The  Main  Module  will  run  properly,  but  not  produce  the 
proper  post  processor  data  records.  However,  Type  4  tasks  should  always  be 
used  to  ensure  that  depot/NRTS  statistics  are  correct.  Figure  40  illustrates 
their  use. 
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Figure  40.  Example  of  Type  4,  6,  7  Tasks. 


C.  USING  THE  MDC  DATA  BASE 


Use  of  the  Common  Data  Extraction  Programs  (CDEP)  is  documented  in 
AFMSMMET  Report  78-4,  and  several  specific  programs  have  been  written  to 
manipulate  this  data.  A  description  of  the  data  base  is  contained  in  the 
appropriate  users  documentation  and  will  not  be  repeated  here. 

(1)  Computations  with  MSBMA 

The  MSBMA  clock  value  may  have  to  be  recomputed  or  adjusted  in  the  course 
of  coding  a  network.  Since  it  is  an  inverse  number,  the  correct  computations 
are  not  always  intuitively  obvious.  The  relationship  of  MSBMA  to  the 
probability  of  a  maintenance  action  on  the  subsystem  is: 

P  =  1 

m  ~~mm — 


To  combine  two  MSBMA  values,  interactions  can  usually  be  ignored  and 
their  probabilities  added: 

1  =1  +  1 

mm -  MSBMA"  "MB1MA” 

TOTAL  1  2 

_ ] _ 

1  +  1 
(MSBMA  MSBMA  ) 

1  2 


or:  MSBMA 

TOTAL 


For  example,  if  an  LRU  with  an  MSBMA  of  every  50  sorties  is  included  in  a 
subsystem  with  a  clock  of  100,  the  new  clock  value  is: 

_ ] _  =  100  =  33 

MSBMA=  "Tl  +  TT"  T 

~m~  w 


The  new  clock  value  is  not  the  average  of  the  two  MSBMA  values,  but  is  a 
number  lower  than  either  of  them.  This  makes  sense  when  one  realizes  that  if 
another  source  of  failure  is  added  to  a  subsystem  that  is  already  failing  every 
50  sorties,  it  is  going  to  fail  more  often.  More  frequent  failures  mean  a 
lower  value  of  MSBMA. 

The  relative  significance  of  MSBMA  values  is  also  deceiving.  Large 
differences  in  large  MSBMA  numbers  are  often  insignificant,  while  even 
relatively  small  differences  in  small  MSBMA  values  represent  important 
differences.  Consider  MSBMA  values  of  2000  and  1000.  The  difference  in  terms 
of  probability  of  a  maintenance  action  is: 
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On  the  other  hand,  the  difference  between  MSBMA  values  of  10  and  5  is: 

P  Diff.  =1  1  1  .1000 

~T~  TO  TO 

The  latter  difference  is  200  times  greater  in  terms  of  frequency  of  failure. 

For  this  reason,  subsystems  which  fail  less  than  once  in  2000  sorties  can  often 
be  ignored  in  building  networks,  but  changes  and  modifications  which  affect  low 
MSBMA  numbers  may  have  considerable  impact  on  the  simulation  results. 

When  the  aircraft  being  modeled  has  more  than  one  of  a  given  subsystem 
installed,  the  unit  MSBMA  taken  from  CDEP  must  be  divided  by  the  number  installed 
to  get  the  correct  total  maintenance  rate.  For  example,  if  an  aircraft  has  two 
(2)  identical  hydraulic  pumps  with  the  same  work  unit  code  identification,  and 
the  data  bank  shows  that  a  single  pump  requires  maintenance  every  fifty  (50) 
sorties,  than  the  average  MSBMA  rate  for  the  two  pumps  will  be  once  every 
twenty-five  (25)  sorties. 

If  the  comparability  study  indicates  a  25%  percent  improvement  in 
reliability  for  a  new  subsystem,  it  will  only  fail  .75  times  as  often;  The  data 
bank  MSBMA  for  comparable  unit  must  be  divided  by  .75  to  get  the  larger  MSBMA 
for  the  new  subsystem. 

(2)  Network  with  Expendable  LRU's  . 

The  remainder  of  this  section  give:;  examples  of  some  more  complex 
networking  problems. 

There  are  many  throwaway  electrical  items  coded  as  on-aircraft  remove/ 
replace  jobs  in  MDC  reporting  which  never  go  into  the  shop.  These  include  such 
items  as  relay  switches,  and  circuit  breakers  throughout  the  aircraft.  The  shop 
data  bank  printout  gives  the  counts  of  items  reported  removed  and  reported  in 
shop,  and  also  shows  a  "6"  probability  of  no  shop.  However,  differences  in  these 
reported  actions  do  not  necessarily  mean  throwaways.  They  could  be  due  to  bad 
reporting  or  have  another  explanation.  LRUs  should  not  be  networked  as 
expendable  unless  it  has  been  confirmed  with  maintenance  technicians  in  the  field. 

(3)  Engine  Network 

MOC  data  is  of  relative  little  value  in  developing  a  network  for  a  basic 
engine.  Data  bank  printouts  are  available  to  show  engine  work  on  aircraft,  work 
on  entire  engines  in  the  engine  shop,  shop  work  on  components  removed  from  the 
engine,  special  inspections,  and  removals  for  access.  However,  so  much  of  the 
unscheduled  maintenance  is  reported  against  04  (inspection)  codes  and  even  09 
(shop  general)  codes,  that  the  data  bank  probabilities  often  are  not  meaningful. 

It  may  not  be  feasible  to  determine  the  frequency  of  engine  removals  from 
MDC  Data  since  there  is  no  standard  way  of  reporting  an  engine  removal  for 
failure.  For  example,  on  the  A-7D  work  unit  codes  23B,  23AJ,  and  removal  for 
access  (to  the  internal  parts)  are  variously  used.  The  AFLC  depot  engine 
managers  require  separate  reporting  of  each  engine  removal  for  cause,  and  these 
are  listed  in  the  monthly  base  K-18  maintenance  summary.  The  average  K-18  count 
over  the  past  year,  from  bases  of  interest,  may  be  the  best  estimate  of  mean 
removal  rates  for  a  comparable  engine. 


The  engine  removal  task  sequence  through  functional  check  flight,  and  the 
proportion  of  on-aircraft  troubleshoot -adjust-fix  to  removal,  should  be  based 
on  information  obtained  from  the  engine  shops  maintaining  comparable  engines, 
and  modified  for  the  maintenance  concept  and  requirements  of  the  new  engine. 

An  example  of  engine  network  is  shown  in  Figure  41.  When  an  engine  is 
changed,  the  aircraft  is  towed  to  the  test  cell  for  trim  and  runup,  and  then 
taken  up  for  a  functional  check  flight.  The  engine  goes  into  the  shop  for 
teardown.  Portions  of  the  engine  may  be  removed  and  replaced,  and  the  engine 
reassembled  for  use  as  a  spare  on  the  next  aircraft  requiring  an  engine  change. 
The  parts  that  were  removed  from  the  engine  are  processed  through  the  field 
shops;  and  when  repaired,  are  returned  to  stock. 

Engine  network  coding  is  shown  in  Figure  42.  The  example  only  depicts  one 
of  the  engine  sections  in  the  shop  to  illustrate  the  technique.  The  first 
asterisk  is  on  the  engine  teardown  task.  This  tells  the  computer  it  is  now 
working  on  an  engine  (WUC  23000)  and  no  longer  holds  up  the  aircraft.  A  "Q" 
task  draws  the  replacement  engine  from  spare  stock  if  available.  At  the  next 
stage  the  "Q"  task  draws  an  assembly  to  be  replaced  on  the  engine.  The  asterisk 
at  this  level  tells  the  computer  that  the  work  is  on  the  removed  assembly  and 
does  not  hold  up  the  engine. 

The  engine  work  center  may  be  subdivided  into  different  sections  which  do 
not  do  each  other's  work.  This  is  one  of  the  maintenance  concept  assumptions 
that  must  be  obtained  from  the  operating  command.  In  Figure  42,  the  flightline 
dispatch  crew  is  coded  432X0,  technicians  assigned  exclusively  to  shop  work  are 
coded  43250,  and  the  crew  dedicated  to  the  test  cell  is  coded  432T0.  The  pilot 
who  does  the  functional  check  flight  is  coded  1115K.  He  is  treated  as  a 
dedicated  resource  and  is  normally  only  available  during  daylight  shifts.  The 
functional  check  flight  is  coded  as  a  maintenance  task  rather  than  as  a  sortie 
task  because  it  is  not  scheduled  on  a  Form  20.  Note  the  use  of  header  cards  to 
supply  nomenclature  for  the  string  of  check  tasks  following  engine  change  or 
on-aircraft  fix.  Also  note  that  resources  are  not  shown  for  these  tasks  when 
they  are  repeated. 

Engine  accessories  and  accessory  systems  removed  and  replaced  on  aircraft 
are  shown  in  separate  networks  {engine  fuel  system,  engine  electrical  system, 
engine  oil  system,  etc.).  These  networks  can  be  satisfactorily  modeled  from  MDC 
data  and  were  not  illustrated  for  this  example. 

(4)  Complex  Avionics  Networks 

The  A-70  forward  looking  radar  (WUC  73AOO)  is  one  of  several  integrated 
subsystems  comprising  the  A-7D  bombing  avionics.  It  is  one  of  the  most  complex 
networking  problems  a  model  builder  is  likely  to  encounter.  Some  of  the 
troubleshooting  and  radar  boresighting  are  reported  under  04  series  work  unit 
codes.  Much  of  the  troubleshooting  is  reported  as  can-not -duplicate  (CND) .  If 
the  initial  troubleshoot  does  not  locate  the  fault,  another  specialist  will  be 
called  in  to  check  his  subsystem,  until  the  problem  is  found  or  clearly  cannot 
be  duplicated.  Some  corrective  actions  require  multiple  removals  for  access, 
and  some  access  removals  are  checked  in  the  shop.  When  NRTS  items  return  from 
depot  they  are  given  a  full  bench  check,  ana  in  some  cases  may  be  NRTS  back 
again. 

These  networks  are  diagramed  in  Figure  43  and  the  coding  is  shown  in 
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Figure  41.  Schematic  of  Engine  Network 
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Figure  42.  Engine  Network  Coding 


Figure  42.  Engine  Network  Coding  (Cont'd) 


Figure  42. 


Figure  44.  It  is  important  that  prior  CNDs  be  shown  in  the  networks  containing 
the  eventual  corrective  action  so  that  the  simulation  clocks  and  frequencies  of 
dispatch  are  not  distorted. 

Access  problems  are  peculiar  to  each  design  and  usually  cannot  be 
extrapolated  from  data  on  another  aircraft.  However,  this  example  of  an  A-7D 
access  problem  is  shown  to  illustrate  the  impact  a  poor  design  can  have,  and 
emphasize  the  importance  of  a  thorough  review  of  mockups,  prototypes,  and  test 
aircraft  to  highlight  and  correct  any  such  condition. 

The  FLR  Air  Navigation  Multiple  Indicator,  WUC  73AE0,  is  mounted  in  the 
cockpit.  There  is  no  difficulty  in  removing  and  replacing  this  indicator, 
however,  there  is  a  small  plug  behind  it  that  sometimes  needs  replacement.  It 
does  not  even  have  a  work  unit  code.  This  plug  can  only  be  reached  if  the 
windshield  is  removed.  Changing  windshields  is  an  11 -hour  job  by  three  (3) 
431C1,  Aero  Repair  Specialists.  Before  they  can  do  it  though,  two  (2)  322X1 s 
must  remove  the  HUD  and  two  (2)  328X3s  must  remove  the  RHAW  indicator.  After 
the  multiple  indicator  and  plug  are  changed  and  all  the  rest  put  back  together, 
the  422X1 s  must  do  a  cabin  pressure  check.  This  requires  322X1 s  to  swing  out 
the  forward  looking  radar  system  so  that  pressure  lines  can  be  hooked  up 
through  the  nose.  After  everything  is  connected,  there  is  a  24-hour  cure  time 
for  the  test.  Because  of  poor  access,  the  failure  of  one  small  plug  can  tie 
down  an  aircraft  for  about  two  days. 

Only  two  (2)  of  the  nine  (9)  FLR  LRUs  are  illustrated  in  Figure  44.  The 
shop  entry  for  the  indicator  coming  off  the  long  access  goes  directly  to  the 
appropriate  shop  tasks,  bypassing  the  "6"  probability.  The  NRTS  (NMCS)  task  is 
followed  by  a  depot  turnaround  time  dummy,  PDEPOT.  The  time  for  this  task  is 
set  on  the  PHASE  program  SPEC  card  and  no  Extended  Form  11  entry  is  required. 

A  task  is  shown  for  bench  check  on  return  from  depot.  This  task  does  not 
appear  in  MDC  data  runs.  A  maintenance  concept  assumption  from  the  operating 
command  and/or  the  opinion  of  experienced  technicians  should  be  sought  to 
determine  whether  such  checks  should  be  in  the  data  base  for  a  new  aircraft. 

One  more  unusual  network  feature  is  shown  in  Figure  44.  When  the  mount 
breaks  or  is  damaged,  the  radar  set  has  to  be  realigned  by  dry  boresighting. 
This  is  a  six-hour  job.  It  is  shown  in  parallel  to  the  "Q"  task  following  the 
"G"  probability  that  determines  whether  the  mount  has  to  be  changed. 
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Hgure  44.  Integrated  Avionics  FLR  Subsystem  Network 


Figure  44.  Integrated  Avionics  FLR  Subsystem  Network  (Cont'd) 
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Figure  44.  Integreted  Avionics  FIR  Subsystem  Netwrk  (Concluded) 


SECTION  VIII 


NETWORKS  FOR  PHASED  AND  PERIODIC  SCHEDULED  MAINTENANCE 

A.  PHASE  INSPECTIONS 

The  number  and  frequency  of  phases  is  a  pokicy  assumption  to  be  provided 
by  the  operating  command.  Networks  for  phased  inspection  work  are  based  on 
phase  procedures  for  similar  aircraft  under  a  similar  inspection  concept  and 
must  be  developed  through  interview  with  wxperienced  technicians  in  the  field. 
The  inspection  work  cards  are  too  detailed  to  network  directly  and  MDC  reporting 
is  far  too  gross.  The  work  done  in  each  phase  and  the  task  sequences,  times  and 
crew  sizes  for  each  AFSC  who  has  a  scheduled  task,  must  be  set  out  in  network 
form.  A  linear  series  of  work  card  tasks  by  the  same  crew  should  be  networked 
as  a  single  task.  The  simplest  phase  network  would  show  each  specialists  crew's 
work  as  one  task  and  all  these  tasks  would  be  shown  in  parallel.  It  is  not 
usually  so  simple  since  there  may  be  constraints  and  access  requirements  among 
the  work  by  various  specialists  that  must  be  identified  and  shown  in  the 
network.  Any  scheduled  removals  which  go  to  the  shop  for  servicing  must  also  be 
shown.  For  example,  hydraulic  filters  are  regularly  replaced  and  sent  to  the 
shop  for  cleaning,  generating  a  task  workload  in  the  hydraulics  shop. 

The  phase  tasks  for  comparable  systems  must  be  carefully  reviewed  in  terms 
of  the  new  aircraft  design  and  maintenance  concepts  in  order  to  delete 
inappropriate  tasks,  modify  others,  and  add  any  new  tasks.  Contractor 
recommendations,  engineering  evaluations,  opinions  of  experienced  maintenance 
personnel,  and  operating  command  policy  assumptions,  need  to  be  sought  and 
considered  in  making  these  judgements. 

Unscheduled  corrective  maintenance  in  phase  may  be  estimated  from  MDC  data 
on  similar  systems  and  subsystems.  It  can  be  networked  as  an  activity,  using 
the  Form  20s,  or  as  a  CALL  section,  using  failure  clocks. 

B.  OTHER  SCHEDULED  INSPECTIONS  AND  TIME  CHANGE  ITEMS 

The  lists  of  04  inspections  in  the  work  unit  code  manuals,  the  data  bank 
runs  on  these  inspections,  and  the  data  bank  runs  for  scheduled  removals,  should 
be  carefully  reviewed  for  all  comparable  aircraft.  A  list  of  inspections  and 
time  changes  applicable  to  the  new  aircraft  must  be  developed,  using  this  data 
as  a  starting  point,  but  adjusting  for  differences  in  design  and  maintenance 
concepts.  Contractor  recommendations  can  be  helpful  if  available,  but  should  be 
verified  by  Air  Force  engineers  and  technicians. 

Inspections  that  occur  at  calendar  intervals  may  be  scheduled  on  the  Form 
20s.  Examples  are  the  45-day  corrosion  wash  for  fighter  aircraft,  or  the  annual 
teardown  and  inspection  of  the  M-61  gatling  gun  on  the  A-7D.  Only  major 
inspections  that  tie  up  the  aircraft  for  half  a  day  or  more  should  be  handled 
this  way.  The  network  should  not  include  a  failure  clock.  It  is  entered 
through  a  dummy  mission  in  the  main  network. 

There  are  many  other  scheduled  inspections  that  are  done  In  conjunction 
with  postflight  when  they  come  due.  This  method  is  cumbersome,  except  w here  the 
inspection  is  done  only  after  completing  certain  types  of  missions.  The  more 
general  way  is  to  use  scheduled  inspection  networks  with  failure  clocks  besed  on 
the  inspection  Interval.  These  clocks  are  only  decremented  and  Interrogated  on 
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Missions  going  to  postfllght.  Coding  conventions  are  similar  to  unscheduled 
Maintenance  networks  except  that  the  task  type  Is  three  (3),  the  work  unit  codes 
and  clocks  have  an  "S*  In  the  last  position,  and  the  nodes  are  six  (6)  digits, 
starting  with  "X".  These  conventions  avoid  any  unintended  duplication  of  nodes 
or  tasks  used  In  unscheduled  Maintenance.  Two  exanple  networks  from  an  A-7D 
model  are  shown  coded  In  Figure  45. 

Every  fifty  (5)  flight  hours,  the  water  collection  bag  on  the  air 
conditioner  Must  be  emptied.  This  Is  done  In  100-hour  Phase  and  during  a 
postfllght,  half-way  between  Phases.  The  433X1  technician  must  remove  the 
water  separator  (41AAL)  to  do  this.  The  whole  job  Is  generally  coded  In  MDC  as 
a  removal  for  access.  The  postfllght  check  Is  shown  In  the  network  as  a 
scheduled  check  every  thirty-six  (36)  postfllghts  (100  flying  hours  at  a  1.8 
sortie  length  and  50%  percent  average  successful  aircraft  turnaround). 

The  cabin  pressure  regulator  (41BCA)  and  pressure  valve  (41BCC)  are 
replaced  every  four  (4)  years  (every  550  sorties  at  peacetime  flying  rates). 

The  job  requires  radar  swing-out  by  AFSC  32221,  access  removal  of  armor  plate 
(11AAL)  by  a  431X1  crew  chief,  and  a  pressure  check  after  the  components  are 
replaced. 

The  postfllght  clock  values  on  scheduled  tasks  must  be  adjusted  when 
scenario  assumptions  are  changed. 
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APPENDIX 


The  Appendix  consists  of  Headquarters  Air  Force  Systems  Command/SDD  letter. 
Subject:  “Use  of  Logistics  Composite  Model  Data  in  Secretary  of  Air  Force 
Program  Reviews”,  with  two  attachments  (1)  System  Readiness  -  Sustainability 
Chart  and  (2)  Major  Aircraft  Program  Offices,  24  September  1980,  Headquarters 
Aeronautical  Systems  Division  (AFSO/EN  letter.  Subject:  “Use  of  Logistics 
Composite  Model  Data  in  Secretary  of  the  Air  Force  Program  Reviews  (Your  Ltr, 
24  Sep  80),“  14  October  1980  and  Headquarters  Air  Force  Systems  Command/SDD 
letter.  Subject:  “Use  of  Logistics  Composite  Model  (LCOM)  Data  for  Use  in 
Secretary  of  the  Air  Force  Program  Review  (SPR)  Sustainability  Chart,”  with 
four  attachments  (1)  Distribution  List,  (2)  Attendance  List,  (3)  Draft 
Sustainability  Chart  and  Instructions,  (4)  Problem  Areas/Considerations  in 
Applying  LCOM  in  Generating  an  SPR  Sustainability  Chart,  8  December  1980 
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MM.Y  TO 
ATTN  Or l 


SIX) 


DEPARTMENT  OF  THE  AIR  FORCE 

HEADQUARTERS  AIR  FORCE  SYSTEMS  COMMAND 
ANDREWS  AIR  FORCE  BASE.  DC  20334 


24  SEP  1980 


auojcct.  Use  of  Logistics  Composite  Model  Data  in  Secretary  of  Air  Force  Program 
Reviews 


to,  HQ  ASD/EN 

1.  HQ  AFSC  is  proposing  System  Readiness  information  be  included  in  the 
Secretary  of  the  Air  Force  Program  Reviews  (SPRs) .  To  that  end,  we  have 
been  working  with  your  Modeling  and  Analysis  Branch  in  developing  a  format 
for  showing  the  ability  of  aircraft  weapon  systems  to  sustain  wartime 

.operations.  The  attached  chart,  "System  Readiness  -  Sustainability,"  is 
an  example  of  the  type  of  data  we  expect  to  see  in  the  SPR.  The  program 
office  will  be  responsible  for  presenting  this  chart  and  the  Logistics 
Composite  Model  (LCOM)  would  be  the  source  of  the  "actual  capability" 
information.  The  ASD  LCOM  group  would  be  tasked  by  the  program  office  to 
provide  support. 

2.  The  specific  purpose  of  the  chart  is  to  convey  the  wartime  requirement 

as  specified  in  the  USAF  War  Mobilization. Plan  (WMP)  and  the  actual  capability 
that  can  be  supported  with  existing  levels  (or  planned  levels  for  systems 
not  yet  deployed)  of  manpower,  spares,  and  support  equipment  for  a  given 
scenario  and  system  reliability.  From  our  discussions  with  Capt  Radoliff, 
ASD/ENESA,  it  appears  the  aircraft  LCOM  data  on  file  would  require  updating 
and  each  model  would  need  to  be  tailored  to  support  our  needs.  There  is 
no  question  that  the  LCOM  can  be  used  to  generate  the  data  we  need  for  a 
sustainability  chart. 


3.  We  have  presented  this  concept  to  AFSC/CC/SD,  AFLC/CC*  HQ  USAF/LE,  and 
HQ  TAC/CV  with  very  favorable  support.  However,  before  we  present  our 
proposal  for  System  Readiness  Reporting  to  the  Air  Force  Council  (21  Oct  80) , 
we  would  like  a  confirmation  of  the  LCOM  applicability  and  the  ability  of 
the  ASD/EN  Modeling  and  Analysis  Branch  to  support  each  of  the  program 
offices,  identified  by  attachment,  in  generating  the  sustainability  chart. 

We  don't  expect  the  LCOM  group  to  develop  this  data  alone.  It  will  have 
to  be  a  combined  effort  by  the  program  office  and  the  using  command.  Our 
whole  objective  is  to  develop  a  reporting  mechanism  that  utilizes  the 
existing  capability  and  data  base  to  give  the  higher  level  Air  Force  managers 
visibility  into  the  readiness  of  each  individual  weapon  system  while  it  is 
still  in  its  early  stages  of  deployment. 


4.  We  would  appreciate  a  response  by  10  Oct  80.  Our  point  of  contact  is 
Maj  Merl  Witt,  AFSC/SDDP,  AUTOVON  858-4027/6160. 


2  Atch 

1.  System  Readiness  -  Sustainability 
Chart 

2.  Major  Aircraft  Program  offices 
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BASED  ON  LOOM  -  EXCLUDES  POL  AND  MUNITIONS 


MAJOR  AIRCRAFT  PROGRAM  OFFICES  REQUIRING  LCOM  SUPPORT 


F-15 

F-16 

E-3A 

£-4 

EF-U1A 

KC-10 

CX  (when  initiated) 
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Maj  Thorapson/ENESA/52837/140ct80/avs 


14  0  Cl  tfOO 

EN 

Us e  of  Logistics  Composite  Model  Date  in  Secretary  of  the  Air  Force 
Program  Reviews  (Your  Ltr,  24  Sep  80) 

HQ  AFSC/SDD 

1.  We  agree  that  the  Logistics  Composite  Model  (LOOM)  appears  to  be  the 
most  appropriate  tool  for  generating  the  type  of  sustainability  data  . 
proposed  for  inclusion  in  Secretary  of  the  Air  Force  Program  Reviews  (SPR®) . 

2*  The  program  proposed  requires  extensive  analysis  manpower.  The  present 
manning  of  the  Modeling  and  Analysis  Branch  cannot  support  requirements  ' 
of  the  magnitude  Indicated  by  attachment  2  of  your  letter.  The  branch  is 
fully  employed  with  ASD  studies  including  the  Avionics  Availability  Study, 
the  Advanced  Tactical  Attack  System  Mission  Analysis,  the  development  of 
Next  Generytion  Trainer  Models,  and  preparations  for  the  C-X  model  develop¬ 
ment.  Upon  release  of  resources  committed  to  the  above  efforts,  the  branch 
could  handle  three  of.'the  proposed  programs.  Preliminary  estimates,  based 
upon  our  level  of  effort  in  past  programs,  indicate  ve  would  need  e 
increase  of  three  people  per  additional  project. 

*  v. 

3.  Aa  LCOM  is  a  versatile  tool  to  accomplish  complex  analysis,  we  can 
discuss  at  your  convenience  the  problems  associated  with  entabliohlng  the 
capability  to  perform  the  magnitude  of  analysis  you  propose.  Our  point  of 
contact  is  Captain  Bill  Radcliffe  or  Mr  Larry  Jordan,  ASD/EKESA,  Autovon 
785-7114. 


ROBERT  F.  IOPINA 
.Colonel,  USAF 
Deputy  for  Engineering 


COORDINATION 
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DEPARTMENT  Or  THE  AIR  FORCe. 

HEADQUARTERS  AIR  FCMCE  SYSTEMS  COMMAND 
ANDREWS  AIR  FORCE  BASE.  DC  20334 


3  DtC  1980 


Use  of  Logistics  Composite  Model  (LCOM)  Data  for  Use  in  Secretary  of 
the  Air  Force  Program  Review  (SPR)  Sustainability  Ch,agfc~— 


See  Distribution  List 


1.  HQ  AFSC/SDD  chaired  a  meeting  on  18  Nov  80  at  Wright-Patterson  AFB  OH 
to  discuss  the  ramifications  of  using  LCOM  to  generate  the  Sustainability 
chart  data  now  required  for  aircraft  programs  briefing  the  SPR.  (Atch  2 
is  the  list  of  attendees.)  The  primary  purpose  won  to  identify  issues 
associated  with  using  LCOM  to  generate  this  chart  and  which  organisation 
could  support  the  various  program  offices,  (See  Atch  3  for  draft  Sustain-* 
ability  chart  and  instructions.) 

2.  Request  that  by  16  January  1980  all  addressees  review  the  positions 
presented  here  and  confirm  their  agreement  related  to  their  program/ 
responsibilities  listed  below.  The  requirement  to  use  the  Sustainability 
chart  is  being  staffed  at  SAF  now  and  wc  anticipate  a  decision  within  a 
month.  The  Sustainability  chart  will  be  presented  at  the  first  opportunity 
to  obtain  meaningful  LCOM  data  after  this  decision. 


3.  In  discussing  the  application  of  LCOM  to  the  F-16,  F-15,  and  EF-111A 
requirements,  it  was  generally  agreed  that  TAC/LGY  could  best  support  the 
F-15  SFO,  that  the  TAC  LCOM  operating  location  in  the  F-16  SPO  could  best 
support  the  F-16  SPO,  and  that  ASD/EN  could  best  support  the  EF-111A  SPO. 
All  three  of  these  efforts  would  require  two  men  working  approximately  6 
months  to  update  the  data  base  and  generate  the  tirsi:  chart  for  the  SPR. 

A  MOA  would  be  required  between  the  F-15  and  F-16  SPOs  and  TAC.  The 
generation  of  the  sustainability  data  will  impact  ongoing  work  and  may 
require  shifting  of  priorities  since  no  additional  manpower  or  funds  are 
available  in  conjunction  with  this  requirement. 


4.  The  application  to  the  other  major  aircraft  would  be: 

a.  E-3A;  The  E-3A  LCOM  would  take  considerably  more  effort  than  the 
F-16,  F-15,  or  EF-131A  models.  Also,  the  LCOM  wartime  scenario  is  outdated 
and  the  impacts  of  the  NATO  E-3A  fleet  are  undefined.  Therefore,  the  require¬ 
ment  for  the  Sustainability  chart  shall  be  deferred  until  an  LOOM  is  developed 
for  the  US/NATO  standard  configured  aircraft. 

b.  A- 10 :  None  of  the  organisations  represented  had  a  current  capability 
for  the  A- 10.  USAFE  is  currently  conducting  an  A-10  surge  sortie  analysis 
which  may  very  easily  support  the  Sustainability  chart  requirement.  HQ  AFSC/ 
SDD  will  follow  up  on  this  with  USAFE  and  advise  the  SPO  accordingly. 
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c.  KC-10:  The  KC-10  LCOM  is  currently  being  developed  by  AFTEC  and 
the  initial  effort  will  be  complete  in  April  1981.  Any  effort  after  April 
should  include  the  sustainability  requirement  for  the  SPR.  Since  the  SPO 
has  no  in-house  LCOM  capability,  an  MOA  between  the  SPO  and  AFTEC  covering 
the  Sustainability  chart  effort  will  be  necessary. 

d.  C-X:  ASD/EN  is  currently  developing  the  LCOM  for  C-X.(  Since  the 
sustainability  briefing  requirement  is  known  at  the  beginning  ;of  this 
development,  there  should  be  no  significant  impact  on  man-years  of  effort 
to  develop  and  maintain  the  Sustainability  chart. 


5.  LCOM  appears  to  be  the  only  practical  simulation  that  could  provide  the 
sustainability  data,  although  there  are  problem  areas  of  data  base  updating, 
scenario  coordination,  and  spares  use  assumptions.  In  addition,  there  will 
be  a  need  to  maintain  a  data  base  and  produce  the  sustainability  analysis  at 
least  once  and  perhaps  twice  a  year.  Use  of  the  LCOM  as  a  data  source  for 
the  SPR  will  mean  that  it  will  be  an  continuing  management  tool  and  that 
additional  resources  will  have  to  be  programed  for  the  duration  of  the 
acquisition  cycle.  Specific  points  and  positions  expressed  in  the  meeting 
are  contained,  in  Atch  4.  Your  comments  or  suggestions  for  dealing  with 
some  of  the  problems  presented  would  be  appreciated. 


6.  We  anticipate  approval  of  the  new  SPR  format  by  early  January  1981 
which  time  we  will  issue  the  direction  needed  to  conduct  this  effort, 
of  contact  for  this  effort  at  HQ  AFSC  is  Maj  Merl  Witt  (AFSC/SDDP) 


858-6160. 


rrr-RY  siiwart 

L>f'" /  I’lr*.  ctor,  Acquisition  Tolley 
DCS/Systcas  -  • 


at 

Point 
AUTOVON 


4  Atch 

1.  Distribution  List 

2.  Attendance  List 

3.  Draft  Sustainability  Chart  and 
Instructions 

4.  Problem  Areas/Considerations  in 
Applying  LCOM  in  Generating  an  SPR 
Sustainability  Chart 
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DISTRIBUTION  LIST 


Program  Offices: 

HQ  ASD/YPL/YPP  WP  AFB  OH  45433 
HQ  ASD/TAF  WP  AFB  OH  45433 
HQ  ESD/YWL  Hanscora  AFB  MA  01730 
HQ  ASD/TAX  WP  AFB  OH  45433 
HQ  ASD/AFH  WP  AFB  OH  45433 
HQ  ASD/RWJ  WP  AFB  OH  45433 
AFALD/YT  WP  AFB  OH  45433 


Meeting  Attendees: 

Jimmy  D.  Bias,  OC-ALC/MMEAL  Tinker  AFB  OK  73145 

Lt  Col  Ronald  Clarke,  HQ  TAC/LGYT  Langley  AFB  VA  23665 

Capt  Del  Atkinson,  HQ  ASD/RWEE  WP  AFB  OH  45433 

Maj  Clyde  Thompson,  HQ  ASD/ENE  WP  AFB  OH  45433 

J.  H.  Nickerson,  HQ  ASD/RWJT  EF-111A  SPO  WP  AFB  OH  45433 

Frank  Evans,  HQ  ASD/SWL  WP  AFB  OH  45433 

Capt  Royce  Kennedy,  HQ  AFTEC/LG  Kirtland  AFB  NM  87117 

Capt  Guy  A.  Chabot,  HQ  ESD/YWX  Hanscora  AFB  MA  07130 

Capt  R.  K.  Rasmussen,  AFALD/YT  WP  AFB  OH  45433 

Maj  Dave  Miller,  AFMSMET  WP  AFB  OH  45433 

2Lt  Michael  A.  Coppelano,  HQ  ASD/TAF  WP  AFB  OH  45433 


Others : 


HQ  USAF/MPME  Wash  DC  20330 
HQ  USAFE/MOM  (Info) 

HQ  PACAF/XPM  Hickam  AFB  HI  96853  (Info) 


Atch  1 
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ATTENDANCE  LIST 


LCOM  SPR  Application  Meeting  -  18  November  1980 


NAME 

Maj  Merlyn  Witt 
Jimmy  D.  Bias 
Lt  Col  Ronald  Clarke 
Capt  Bob  Yunag 

Kenneth  Bawman 

Jeffrey  Melaragno 

Capt  Jim  Lowell 

Gene  Gross 

Capt  Del  Atkinson 

Maj  Clyde  Thompson 

1 Lt  Michael  R.  Clark 

Jitti  Nickerson 

2Lt  Michael  S.  Coppelano 

Ben  Wince 

Frank  Evans 

Mary  Case 

Richard  Cronk 

2Lt  Eugene  R.  Richards,  Jr 
Capt  John  Koch 
Capt  Royce  Kennedy 
Capt  Guy  A  Chabot 

W.  Shaughnessy 

Capt  R.  K.  Rasmussen 
Margaret  Joering 
Capt  Bill  Radcliffe 
Maj  Dave  Miller 


office  TELEPHONE  NUMBER 


HQ  AFSC/SDD 
OC-ALC/MMEAL 
HQ  TAC/LGYT 
ASD/YP 

4400  MES/OLAA  (TAC) 
ASD/ADD 
ASD/ENESA 
HQ  AFTEC 
ASD/AFEE 
ASD/RWEE 
ASD/ENESA 
AFALD/XRSA 
ASD/RWJL  EF111A  SPO 
ASD/TAF 
ASD/AWL 
ASD/AWL 
ASD/ENESA 
ASD/ENESA 
ASD/ENESA 
ASD/ENS-A/C 
HQ  AFTEC/LG 
HQ  ESD/YWXP 

HQ  ESD/YWXP 

AFALD/YT 

AFALD/YT 

ASD/ENESA 

AFMSMET 


AUTOVON  858-4027 
AUTOVON  735-6008 
AUTOVON  432-3427 
AUTOVON  785-2711 

AUTOVON  785-6633 
AUTOVON  785-7114 
255-0346 
255-2861 

AUTOVON  785-5816 
AUTOVON  785-2837 
AUTOVON  785-5700 
AUTOVON  785-6424 
255-3266 

AUTOVON  785-3619 
AUTOVON  785-4229 
255-7114 

AUTOVON  785-7114 
AUTOVON  785-7114 
AUTOVON  785-6582 
AUTOVON  244-0346 
AUTOVON  478-10001 
MITRE  2208 
AUTOVON  478-1001 
MITRE  2209 
785-5624 

AUTOVON  785-5015 
AUTOVON  785-7114 
AUTOVON  787-6393 
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TITLE:  SYSTEM  READINESS  (SUSTAINABILITY) 


4.  If  the  system  capability  Is  less  than  the  requirement,  an  explantory  chart  must  be 
prepared  which  identifies,  as  a  minimum,  the  limiting  element(s)  (manpower,  spares,  sup¬ 
port  equipment  utilization,  or  system  reliability).  Any  factors  not  included  in  the  LCOM 
which  might  adversely  affect  sustainability  should  be  identified. 
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C-X:  ASO/EN 

The  initial  presentation  of  this  chart  will  not  be  required  until  the  LOOM  data  base  is 
updated  by  the  supporting  LCOM  group  (This  may  require  approximately  six  months). 


PROBLEM  AREAS/CONSI DERAT I OHS  IN  APPLYING  LOOM 
IN  GENERATING  AN  SPR  SUSTAINABILITY  CHART 


EF-111A 

ASD/EN  proposes  a  6-month  effort  involving  two  analysts  to  generate  the 
EF-111A  SPR  Sustainability  chart  using  an  EF-.111A  LCOM.  This  model  and 
detailed  scenario  Information  are  available  from  HQ  AFTEC.  The  model 
would  b6  updated  in  cooperation  with  HQ  TAC/XPM  efforts. 

Of  primary  importance  is  the  cooperation  and  support  of  the  EF-111A  SPO 
Their  funds  would  be  required  for  TDY  purposes.  The  EF-1UA  DPML  would 
have  to  be  Intimately  involved  in  the  development  of  the  combat  scenario. 

Through  the  DPML,  AFLC,  ALD,  and  the  system  manager  would  be  involved  in 
the  development  of  the  sustainability  chart.  AFTEC  and  TAC  would  continue 
their  involvement  throughout  the  effort.  The  Air  Staff  would  also  have  to 
coordinate  on  scenario  development  and  LCOM  analysis  results. 

C-X  PROGRAM 

This  is  an  excellent  opportunity  to  apply  a  joint  modeling  group  to  develop¬ 
ment  of  an  LCOM  to  measure  supportability  (also  produce  sustainability  chart). 
With  the  proper  emphasis  from  all  involved  parties,  this  tool  could  be  very 
effective  in  tradeoffs,  capabilities,  and  other  analyses. 

Suggested  group  should  contain  one  full-time  logistician,  one  full-time  using 
command  representative,  one  SPO  representative,  and  one  modeler  from  the  LCOM 
shop.  After  initially  building  the  model,  the  support  can  be  reduced  to  two 
people  full  time  to  keep  the  model  up-to-date. 

The  model  can  be  developed  to  perform  supportabillty  analyses  in  addition  to 
manpower  requirements,  and  can  be  done  quickly  with  the  model.  The  most 
difficult  task  Is  the  scenario  development  and  scenario  coordination.  There 
Is  no  established  procedure  for  coordinating  a  usage  scenario.  It  Is  currently 
coordinated  by  the  modeler  who  determines  should  coordinate  on  it. 

E-3A 

The  tasking  for  the  System  Readiness  Sustainability  chart  for  the  E-3A  program 
shall  be  deferred  until  an  LCOM  Is  developed  for  the  US/NATO  standard-configured 
aircraft  system.  The  rationale  is  that  the  LCOM  wartime  scenario  for  E-3A  core¬ 
configured  aircraft  is  outdated  and  impacts  from  US  support  of  the  NATO  E-3A 
fleet  are  undefined.  Also  an  update  of  the  present  E-3A  LCOM  would  require 
approximately  six  people  (TAC  and  AFLC)  to  provide  updated  scenarios.  Time 
required  would  be  12-18  months. 

Any  MOA  or  LOA  should  be  negotiated  between  MAJCOMs.  The  Inputs  for  a  briefing 
to  the  Secretary  should  be  coordinated  MAJCOM  positions  on  a  particular  subject. 
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F-16 


HQ  TAC/XPH  (LOOM)  has  an  F-16  sustained  wartime  data  base  which  is  updated 
on  an  annual  basis.  Additionally,  a  surge  data  base  exists;  although,  it 
is  over  a  year  old.  While  a  surge  excursion  was  performed  sometime  ago, 
there  may  not  be  a  viable,  approved  surge  scenario  available.  The  Sustain¬ 
ability  SPR  chart  would  require  two  people  working  6  months  and  could  be 
done  by  the  F-16  TAC  operating  location,  which  was  placed  within  the  F-16 
SPO  to  provide  support  for  projects  similar  to  this  SPR  chart.  The  data 
base  exists  to  support  this  requirement,  and  it  can  be  made  available  to  an 
AF  agency  which  can  support  the  requirement. 

There  is  a  potential  problem,  however.  Is  that  TAC  feels  the  requirement  for 
the  operating  location  diminishing,  and  It  could  be  phased  out  within  1$  years. 
XPM  may  not  have  the  resources  to  support  an  SPR  requirement,  unless  high 
level  directives  establish  the  priority. 

F-15 

Since  LCOM  Is  a  relatively  resource  Intense  analysis  process,  with  a  scarcity 
of  trained  resources,  a  position  was  taken  regarding  the  most  logical  manner 
to  get  the  SPR  studies  Initiated.  This  position  did  not  consider  current 
tasking  of  the  organizations  concerned  and  recognized  coordination  required. 

To  produce  a  F-15  SPR  chart  would  require  two  persons  working  near  full  time 
approximately  6  months.  This  would  consume  approximately  one-half  of  the 
TAC  LG  LCOM  capability. 

A  considerable  effort  In  performing  an  LCOM  capability  assessment  Is  associated 
with  the  development  and  coordination  of  an  LCOM  scenario  which  contains  the 
operational  factors  and  the  major  assumptions.  Also  the  collection  and 
processing  of  Information  related  to  the  current  spares  posture  and  support 
equipment  availability  Is  a  major  workload. 

An  MOA  between  the  SPO  and  organization  doing  the  study  and  perhaps  the  SM 
Is  highly  desirable  If  not  an  absolute  necessity. 

KC-10 


AFTEC  is  presently  developing  an  LCOM  analysis  fo**  the  KC-10.  The  Initial 
“first-cut"  on  this  analysis  will  be  completed  In  March  to  April  1981.  After 
review  of  this  “first-cut"  LCOM  analysis,  SAC,  AFTEC,  and  the  KC-10  Joint 
Program  Office  will  determine  If  alternate  scenarios  are  appropriate  for 
future  LCOM  consideration. 

An  Issue  of  some  concern  Is  that  the  first  scenario  developed  for  the  KC-10 
does  not  fully  evaluate  the  advertised  utilization  rates.  The  commercial 
aspects  of  the  KC-10  program  especially  In  the  supply  support  area  may  suggest 
that  future  LCOM  efforts  are  not  required  on  a  recurring  basis.  Future  LCOM 
analysis  after  the  AFTEC  effort  will,  therefore,  be  a  subject  of  future  consid¬ 
eration  In  conversations  between  the  JPO  and  SAC. 
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AFTEC  does  not  have  a  SAC,  MAC,  TAC,  and  AFLC  approved  scenario.  SAC  and 
AFLC  {the  JPO)  have  provided  AFTEC  with  an  initial  first-cut  scenario.  Future 
LCOM  efforts  Bust  include/consider  an  "approved"  scenario.  This  effort  to  coroe 
up  with  an  approved  scenario  will  possible  noc  begin  until  after  the  March  1981 
review  of  AFTEC' s  first -cut. 

GENERAL 


A  quantitative  "systems*  approach  to  assessing  the  sustainability  of  aircraft 
systems  is  desirable.  LCOM  is  a  sensible  alternative;  however,  there  maybe 
severe  limitations  in  terras  of  resources  (computer  capability,  people)  through¬ 
out  the  existing  LCOM  community.  The  major  problem  will  be  the  "scenario" 
development,  including  the  data  base  and  assumptions.  Several  organisations 
must  provide  Inputs.  A  valid  assessment  can  be  made  only  if  all  applicable 
organizations  provide  inputs,  concur  on  assumptions,  etc. 

The  LCOM  Is  a  "unit  level"  assessment.  It  does  not  provide  a  fleet  level  view. 
It  also  does  not  address  munitions.  The  Air  Force  should  seriously  consider 
contracting  for  a  new  model  which  gives  upper  level  management  a  "macro"  view 
of  the  total  fleet  capability. 
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